Как сделать ссылку прокси
Проксируем и спасаем
ноября мир изменился и больше никогда не будет таким же как прежде. В российском интернете появилась цензура — общеизвестный уже список запрещенных сайтов. Для одних это важнейшая политическая тема, для других повод изучить технологии шифрования и защиты анонимности, для третьих просто очередной странный закон, который приходится исполнять на бегу. Мы же поговорим о технологическом аспекте.
В данном пособии мы узнаем как быстро и просто сделать рабочее зеркало любого сайта, что позволяет сменить IP и назначить любое доменное имя. Мы даже попробуем спрятать домен в url, после чего можно сохранить локально полную копию сайта. Все упражнения можно сделать на любом виртуальном сервере — лично я использую хостинг Хетцнер и OS Debian. И конечно мы будем использовать лучший веб-сервер всех времен и народов — NGINX!
К этому абзацу пытливый читатель уже приобрел и настроил какой нибудь выделенный сервер или просто запустил Linux на старом компьютере под столом, а так же запустил Nginx последней версии со страничкой «Save me now».
Перед началом работы необходимо скомпилировать nginx c модулем ngx_http_substitutions_filter_module, прежнее название — substitutions4nginx.
Дальнейшая конфигурация будет показана на примере сайта www.6pm.com. Это сайт популярного онлайн магазина, торгующего товарами с хорошими скидками. Он отличается категорическим нежеланием давать доступ покупателям из России. Ну чем не оскал цензуры капитализма?
У нас уже есть работающий Nginx, который занимается полезными делом — крутит сайт на системе Livestreet о преимуществах зарубежного шоппинга. Чтобы поднять зеркало 6pm прописываем DNS запись с именем 6pm.pokupki-usa.ru который адресует на IP сервера. Как вы понимаете, выбор имени для суб-домена совершенно произволен. Это имя будет устанавливаться в поле HOST при каждом обращении к нашему новому ресурсу, благодаря чему на Nginx можно будет запустить виртуальный хостинг.
В корневой секции конфигурации nginx прописываем upstream — имя сайта-донора, так будем его называть в дальнейшем. В стандартных гайдах сайт обычно называется back-end, а reverse-proxy называется front-end.
Дальше нужно создать секцию server, вот как она выглядит
Стандартные директивы listen и server определяют имя виртуального хоста, при обращении к которому будет срабатывать секция server. Файлы логов лучше сделать отдельными.
$uri — переменная nginx, которая содержит путь из HTTP запроса
Префикс “@” задаёт именованный location. Такой location не используется при обычной обработке запросов, а предназначен только для перенаправления в него запросов. Такие location’ы не могут быть вложенными и не могут содержать вложенные location’ы
В нашем случае конструкция используется только для подмены файла robots.txt, чтобы запретить индексацию содержимого сайта. Однако таким образом делается зеркалирование и кеширование в nginx.
include ‘6pm.conf’ — логика модуля substitutions.
proxy_cookie_domain — новая функция, которая появилась в nginx версии 1.1.15, без этой директивы приходилось делать так. Больше не нужно ломать голову, прописываете одну строчку и куки просто начинают работать.
proxy_set_header Accept-Encoding «»; — очень важная команда, которая заставляет сайт донор отдавать вам контент не в сжатом виде, иначе модуль substitutions не сможет выполнить замены.
proxy_set_header Host — еще одна важная команда, которая в запросе к сайту донору выставляет правильное поле HOST. Без нее будет подставляться имя нашего прокси сервера и запрос будет ошибочным.
proxy_pass — прямая адресация не работает в именованном локейшине, именно поэтому мы прописали адрес сайта донора в директиве upstream.
proxy_redirect — многие сайты используют редиректы для своих нужд, каждый редирект нужно отловить и перехватить здесь, иначе запрос и клиент уйдет за пределы нашего уютного доменчика.
Теперь посмотрим содержимое 6pm.conf. Я не случайно вынес логику трансформации в отдельный файл. В нем можно разместить без какой либо потери производительности тысячи правил замены и сотни килобайт фильтров. В нашем случае мы хотим лишь завершить процесс проксирования, поэтому файл содержит всего 5 строк:
Меняем коды google analytics:
Уверяю, что это самая безобидная шалость из возможных. У нас появится статистика посещений, а у сайта донора эти визиты — исчезнут.
Меняем все прямые ссылки на новые.
Как правило, в нормальных сайтах все картинки лежат на CDN сетях, которые не утруждают себя проверкой источника запросов, поэтому достаточно замены ссылок только основного домена. В нашем случае 6pm выпендрился и разместил часть картинок на доменах, которые отказывают посетителям из России. К счастью, модуль замены поддерживает регулярные выражения и не составляет никакого труда написать общее правило для группы ссылок. В нашем случае обошлось даже без regexp, просто поменяли два символа в домене. Получилось так:
Единственное, но очень серьезное ограничение модуля замены — он работает только с одной строкой. Это ограничение заложено архитектурно, поскольку модуль работает на этапе, когда страница загружена частично (chunked transfer encoding) и нет никакой возможности выполнить полнотекстовый regexp.
Все, можно посмотреть на результат, все работает, даже оплата заказа проходит без затруднений.
С п.1 все просто — мы заменяем все ссылки на новый путь с поддиректорией
С п.3 так же просто — мы ничего не трогаем и все работает само если не использовался атрибут base href. Если этот атрибут используется, что бывает крайне редко в современных сайтах, то достаточно его заменить и все будет работать.
Теоретически можно написать достаточно общий универсальный regexp, который сумеет выбрать исключительно нужные паттерны для замены, на практике гораздо проще написать несколько простых regexpов, которые будут по частям переводить нужные ссылки.
Вернемся к нашему пациенту:
Конфигурация сервера претерпела некоторые изменения.
Во-первых, вся логика перенесена из директивы sever напрямую в location. Нетрудно догадаться, что мы решили создать директорию /6pm в которую будем выводить проксируемый сайт.
proxy_cookie_path / /6pm/ — переносим куки из корня сайта в поддиректорию. Это делать не обязательно, но в случае если проксируемых сайтов окажется много, их куки могут пересечься и затереть друг друга.
rewrite ^/6pm/(.*) /$1 break; — эта магия вырезает из клиентского запроса поддиректорию, которую мы добавили, в результате директива proxy_pass отправляет на сервер-донор корректное значение.
Чуть сложнее стало ловить редиректы. Теперь все ссылки на корень нужно перебросить на /6pm.
Посмотрим на логику трансформации:
Во-первых, мы включили фильтрацию файлов css и javascript (парсинг html включен по-умолчанию)
Во-вторых, начинаем аккуратно находить и заменять разные типы ссылок относительно корня. Нам попался средней сложности сайт, в котором часть скриптов содержат такие пути.
К сожалению, мне не удалось до конца написать фильтр для случая поддиректории. Я не дошел до преобразования динамических запросов скриптов корзины с покупками, хотя не сомневаюсь что это решаемо. Просто моих знаний в Javascript не достаточно чтобы выполнить необходимую отладку, буду рад советам как запустить корзину покупок, которая сейчас в упомянутом примере не работает.
В любом случае, это, возможно, первый гайд, в котором описан метод проксирования в поддиректорию.
Разбираем методы проксирования на основе HAProxy
Недавно пришлось разбираться с проксированием доступа к веб-серверам с помощью HAProxy. Основная проблема оказалась в шифрованном доступе. Кому интересна эта тема, добро пожаловать под кат.
Есть в нашей компании ряд веб-серверов. Для экономии адресов доступ к ним организован через HAProxy. Примерно вот так:
При этом конфигурация самого HAProxy крайне простая (пример №1):
backend mytest1_web
mode http
cookie SERVERID insert indirect nocache
server mytestweb1 192.168.1.5:80 check cookie mytestweb1
backend mytest2_web
mode http
cookie SERVERID insert indirect nocache
server mytestweb2 192.168.1.10:80 check cookie mytestweb2
Здесь и далее я буду приводить не полные примеры конфиг-файла, а только интересующие нас куски.
Предельно просто — слушаем 80 порт и разбираем весь входящий траффик. Если запрашивается mytest1.loc, то он попадает в access-list is_mytest1, в этом случае используется бэкенд mytest1_web, в котором мы перенаправляем траффик на внутренний хост 192.168.1.5, где у нас и находится данный сайт. Аналогично и для mytest2.loc. Все предельно просто и при этом мы экономим реальные IP адреса.
Встал вопрос отказоустойчивости, тем более что в соседнем городе у нас тоже есть сервера, где мы можем поднять данные веб-сайты. Ну и есть виртуалка с линуксом в облаке Amazon, которая делает тоже самое, но для сайтов, расположенных в облаке. Можем ли мы использовать 2 HAProxy подряд? Поднимаем примерно такую тестовую схему и смотрим:
Конфигурации HAProxy2 и HAProxy3 не изменились, однако в HAProxy1 добавился параметр балансировки (пример №2):
backend mytest1_web
mode http
balance roundrobin
cookie SERVERID insert indirect nocache
server HAProxy1 1.1.1.1:80 check cookie haproxy1_1
server HAProxy2 3.3.3.3:80 check cookie haproxy2_1
backend mytest2_web
mode http
balance roundrobin
cookie SERVERID insert indirect nocache
server HAProxy1 1.1.1.1:80 check cookie haproxy1_3
server HAProxy2 3.3.3.3:80 check cookie haproxy2_3
Все отлично заработало. Казалось бы, можно радоваться, но тут сайты решено было переделать под работу через SSL. И начались проблемы.
Вернемся к началу и рассмотрим все с начала. Первое допущение — нам не нужно шифровать траффик между прокси-сервером и самим сайтом. Второе — нам не нужно заботиться о привязке сертификата к сайту, то есть у нас везде используются самоподписанные сертификаты.
Что нам нужно сделать? Сгенерировать и установить на нашем HAProxy сервере самоподписанный сертификат, тогда клиент, обращаясь на сайт, будет попадать на наш прокси-сервер, брать его сертификат, устанавливать защищенное соединение с сервером и дальше перенаправляться на веб-сайт. Причем для всех сайтов, находящихся за прокси-сервером, будет использоваться один сертификат.
Итак, приступим. Генерируем:
Записываем в один файл:
cat server.key > /etc/ssl/mytest.loc.pem
cat server.crt >> /etc/ssl/mytest.loc.pem
И редактируем конфигурацию HAProxy(пример №3):
backend mytest1_web
mode http
balance roundrobin
cookie SERVERID insert indirect nocache
server mytestweb1 192.168.1.5:80 check cookie mytestweb1
backend mytest2_web
mode http
balance roundrobin
cookie SERVERID insert indirect nocache
server mytestweb2 192.168.1.10:80 check cookie mytestweb2
Кстати, проверять конфигурацию перед перезапуском — это очень полезная привычка:
Проверяем и видим, что все отлично работает.
Что ж, а теперь возьмем случай, когда на каждом сайте свой сертификат, причем не самоподписанный, а купленный. И в нем есть строгая привязка к имени сайта. В этом случае мы можем решить вопрос двумя способами: разместить сертификаты для сайтов на HAProxy сервере или проксировать TCP вместо HTTP. Но в обоих случаях мы не сможем обойтись одним IP адресом для двух наших сайтов.
Рассмотрим первый случай:
Все отличие данного случая от предыдущего(с самоподписанными сертификатами) только в том, что здесь нам придется слушать отдельные интерфейсы и выдавать сертификат в зависимости от интерфейса (пример №4):
backend mytest1_web
mode http
balance roundrobin
cookie SERVERID insert indirect nocache
server mytestweb1 192.168.1.5:80 check cookie mytestweb1
backend mytest2_web
mode http
balance roundrobin
cookie SERVERID insert indirect nocache
server mytestweb2 192.168.1.10:80 check cookie mytestweb2
Вроде все понятно, если траффик пришел на интерфейс с адресом 1.1.1.1, значит, клиент запрашивает сайт mytest1.loc. Значит, мы выдаем ему сертификат этого сайта и дальше проксируем на backend mytest1_web.
Во-втором случае мы пробрасываем полностью весь TCP-траффик, который пришел к нам на 443 порт. Это стоит сделать, например, тогда, когда вы по каким-либо причинам не хотите, чтоб сертификаты сайтов хранились на прокси сервере. Или, например, не доверяете внутренней сети между прокси и веб серверами.
Конфигурация HAProxy будет примерно следующая(пример №5):
frontend mytest1_frontend
bind 1.1.1.1:443
mode tcp
use_backend mytest1_webssl
backend mytest1_webssl
mode tcp
option ssl-hello-chk
server mytestweb 192.168.1.5:443
frontend mytest2_frontend
bind 9.9.9.9:443
mode tcp
use_backend mytest2_webssl
backend mytest2_webssl
mode tcp
option ssl-hello-chk
server mytestweb 192.168.1.10:443
Вроде вполне понятная конфигурация. Наверно, стоит сказать, что поскольку мы прокидываем весь TCP траффик, мы не можем анализировать его, и поэтому наличие любых access-lists в frontend части будет выдавать ошибку.
Настало время вернуться к нашей задаче с разделением web сайтов по разным городам. Для начала рассмотрим более простой случай:
Поскольку между HAProxy1 и HAProxy2 у нас интернет, то даже при использовании самоподписанных сертификатов мы не можем использовать HTTP PROXY MODE на HAProxy1, иначе теряется весь смысл в шифровании такого соединения. Будем использовать на HAProxy1 tcp mode, а на HAProxy2 http mode.
Конфигурация для HAProxy1 (пример №6):
frontend https_frontend
bind *:443
mode tcp
use_backend https_web
backend https_web
mode tcp
option ssl-hello-chk
server haproxy2 1.1.1.1:443
Конфигурация для HAProxy2 будет идентична конфигурации в примере №3ю
Настало время добавить вторую часть серверов: 
Конфигурация для HAProxy1 (пример №7):
frontend https_frontend
bind *:443
mode tcp
use_backend https_web
backend https_web
mode tcp
balance roundrobin
option ssl-hello-chk
server haproxy2 1.1.1.1:443 check
server haproxy3 3.3.3.3:443 check
Все отличие данного примера от предыдущего — наличие балансировки и отказоустойчивости между HAProxy2 и HAProxy3, которые по нашему условию должны находиться в разных городах.
Что ж, последний пример будет в случае наличия несамоподписанных сертификатов. Предположим, что они установлены на HAProxy серверах — как в примере №4:
Конфигурация для HAProxy1 будет как в предыдущем примере, а для HAProxy2 — как в примере №4. Такая же для HAProxy3 с небольшими изменениями реальных адресов а frontend части.
Также стоит сказать, что можно все 3 HAProxy сервера настроить в TCP MODE — и это тоже будет работоспособное решение.
Ну и напоследок хотелось бы сказать: если кто-то знает какие-то принципиально отличающиеся решения для данной задачи, буду признателен, если вы поделитесь ими.
Небольшой апдейт. Мне тут подумалось, что если мы пробрасываем трафик, то нам незачем использовать на HAProxy2 и HAProxy3 набор различных IP адресов, гораздо проще просто использовать разные порты.
Давайте рассмотрим вот такую схему: 
backend mytest1_web
mode http
balance roundrobin
cookie SERVERID insert indirect nocache
server mytestweb1 1.1.1.1:80 check cookie mytestweb1
server mytestweb1 2.2.2.2:80 check cookie mytestweb1
backend mytest2_web
mode http
balance roundrobin
cookie SERVERID insert indirect nocache
server mytestweb2 1.1.1.1:80 check cookie mytestweb2
server mytestweb2 2.2.2.2:80 check cookie mytestweb2
backend mytest3_web
mode http
balance roundrobin
cookie SERVERID insert indirect nocache
server mytestweb3 2.2.2.2:80 check cookie mytestweb3
frontend mytest1_frontend
bind 3.3.3.3:443
mode tcp
use_backend mytest_webssl1
backend mytest_webssl1
mode tcp
balance roundrobin
option ssl-hello-chk
server mytestweb1 1.1.1.1:55551
server mytestweb2 2.2.2.2:55551
frontend mytest2_frontend
bind 4.4.4.4:443
mode tcp
use_backend mytest_webssl2
backend mytest_webssl2
mode tcp
balance roundrobin
option ssl-hello-chk
server mytestweb1 1.1.1.1:55552
server mytestweb2 2.2.2.2:55552
frontend mytest3_frontend
bind 5.5.5.5:443
mode tcp
use_backend mytest_webssl3
backend mytest_webssl3
mode tcp
balance roundrobin
option ssl-hello-chk
server mytestweb2 2.2.2.2:55553
И конфигурация HAProxy3:
frontend mytest1_frontend
bind 2.2.2.2:55551 ssl crt /etc/ssl/mytest1.loc.pem
mode http
option httpclose
option forwardfor
reqadd X-Forwarded-Proto:\ https
use_backend mytest1_web
frontend mytest2_frontend
bind 2.2.2.2:55552 ssl crt /etc/ssl/mytest2.loc.pem
mode http
option httpclose
option forwardfor
reqadd X-Forwarded-Proto:\ https
use_backend mytest2_web
frontend mytest3_frontend
bind 2.2.2.2:55553 ssl crt /etc/ssl/mytest3.loc.pem
mode http
option httpclose
option forwardfor
reqadd X-Forwarded-Proto:\ https
use_backend mytest3_web
backend mytest1_web
mode http
balance roundrobin
stats enable
cookie SERVERID insert indirect nocache
server mytestweb1 192.168.1.5:80 check cookie mytestweb1
backend mytest2_web
mode http
balance roundrobin
stats enable
cookie SERVERID insert indirect nocache
server mytestweb2 192.168.1.10:80 check cookie mytestweb2
backend mytest3_web
mode http
balance roundrobin
stats enable
cookie SERVERID insert indirect nocache
server mytestweb3 192.168.1.15:80 check cookie mytestweb3
Что такое прокси-сервер и как его настроить на Windows, Android, iOS, MacOS, Linux и в браузере
Всем привет! Сегодня я расскажу вам – как произвести установку и настройку прокси-сервера на всех известных устройствах: Windows, iOS, MacOS, Android и Linux. Прежде чем мы приступим, давайте я кратенько расскажу – а что же такое прокси?
Прокси – это некий посредник в сети, которого использует клиент для того, чтобы подключаться к глобальной сети интернет. То есть вы будете не напрямую подключаться к интернету, а через удаленный сервер, который также находится в глобальной сети. При этом ваш IP адрес будет изменен на другой.
Многие спросят: а чем же прокси отличается от VPN? В VPN при подключении к выделенному серверу весь трафик зашифрован, и поэтому если его перехватят злоумышленники, спец службы или ваш провайдер, то его нельзя будет расшифровать. Итог такой:
Так что прежде чем приступать к настройке, подумайте, что именно вам нужно: VPN или Proxy. По настройке и использованию бесплатного VPN у нас есть отдельная статья и подробные инструкции для каждого из устройств.
Также вам нужно найти настройки прокси, коих достаточно много в интернете – просто вбиваем в поисковик фразу «Бесплатные прокси» и находим настройки для подключения. Ещё один момент – перед настройкой узнайте свой внешний IP адрес, если он изменится после конфигурации, то вы все сделали правильно. Для этого достаточно в «Яндексе ввести» фразу: «Мой IP».
ПОМОЩЬ СПЕЦИАЛИСТА! Если у вас будут какие-то вопросы, дополнения или вы нашли ошибку, то пишите об этом в комментариях.
Windows 10
Windows 7
Кстати, таким же образом можно включить и настроить прокси сервер для локальной сети на Windows 10.
MAC OS
Linux
Открываем терминал и вводим команды:
$ export ftp_proxy=http://proxy:port/
$ export http_proxy=http://proxy:port/
$ export https_proxy=https://proxy:port/
Здесь я показал пример подключения отдельных прокси для разных протоколов. Вместо «proxy» вводим IP адрес сервера, а через двоеточие (:) порт. Если же ваш прокси использует аутентификацию с логином и паролем, то вводим такие команды:
$ export http_proxy=http://login:password@proxy:port/
$ export https_proxy=https://login:password@proxy:port/
$ export ftp_proxy=http://login:password@proxy:port/
ПРИМЕЧАНИЕ! Если в пароле используются специальные символы, то их нужно заменить по таблице ASCII.
Чтобы отключиться от сервера, нужно ввести команды:
$ unset http_proxy
$ unset https _proxy
$ unset ftp_proxy
Android
Как вы поняли данные настройки подходят только для WiFi подключения. Если же вы хотите подключить прокси для мобильного интернета, то можно использовать сторонние программы или браузеры, в настройках которых также можно сконфигурировать Proxy-соединение. Но я все же вам рекомендую использовать именно VPN, о котором я говорил в самом начале.
iOS (iPhone и iPad)
В браузере
Прежде чем начать настройку вам нужно очистить файлы Cookie, которые обычно отправляются на сервера сайтов, и они могут быть использованы для авторизации. Просто за счет «куки» файлов конечный сервер сможет определить ваш старый IP адрес.
Нажмите одновременно на клавиши «Ctrl+Shift+Del». Выделите галочкой «Cookie» и очистите данные с кэша браузера.
FireFox
Google Chrome, FireFox, Opera
Все настройки делают в операционной системе – смотрите главы: Windows 7 и 10 выше. Напомню, что у Оперы есть свой отдельный выделенный бесплатный VPN – для активации нажмите на значок «VPN» левее адресной строки и включите функцию. Вы также можете изменять расположение сервера ниже.