Комментарии 52
а можно все это делать по именам доменов а не ip адресам?
Я себе настроил немного наоборот: на своём VPN-сервере крутится OpenVPN, ничего не знающий о блокировках.
А в качестве клиента – роутер Микторик, на котором запущен скрипт, обходящий заданный список доменов, собирающий их IP-адреса и пускающий их через VPN.
У меня поднят обычный proxy-server на машине, у которой есть доступ к недоступным с домашней машины ресурсам. На домашней машине PAC (proxy auto configuration file) файл, в котором написано, куда ходить в случае какого запроса. Ну и естественно, если запрос включает в себя недоступные ресурсы — то браузер идет к прокси-серверу
В принципе можно SOCKS proxy и за VPN расположить.
Самое сложное — найти, куда положить скрипт для WPAD.
Как vpn узнает что обратились к нужному айпишнику, если идет блокировка запросов абонентов на уровне URL, IP, и DNS?
Все запросы к DNS заворачиваются в VPN по-умолчанию?
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
#Ключевой момент -- прописываем маршруты на DNS-сервера через VPN
push "route 8.8.8.8 255.255.255.255 vpn_gateway"
push "route 8.8.4.4 255.255.255.255 vpn_gateway"
#Ключевой момент — прописываем маршруты на DNS-сервера через VPN
push «route 8.8.8.8 255.255.255.255 vpn_gateway»
push «route 8.8.4.4 255.255.255.255 vpn_gateway»
И потом, VPN — это обычный сервис по собственной безопасности, в бесплатном ВайФай московского метро, в гостиницах и тп. Лучше весь трафик через него пропускать, меньше рисков нарваться на школоло-скрипткидди.
А зачем он, если есть Pritunl?
10-30 минут, включая разворачивание хостинга и дичтрибутива, — и свой OpenVPN-сервер с web-панелью, неограниченным числом клиентов, "организаций", и т. д.,
Следственные мероприятия проводятся на основании статьи 111 Криминального кодекса Украины – «государственная измена». Виновным по данной статье грозит лишение свободы сроком на 12-15 лет с конфискацией имущества.
https://bitbucket.org/ValdikSS/antizapret
Небольшая доработка напильником требуется. (он по-умолчанию настроен на github-репозиторий с дампом БД Роскомнадзора)
Естественно для этого необходим свой сервер...((
Однако побороть блокировку сервисов google (developers/cloud/issuetracker/...) я не смог, так как google все свои сервисы пропускает через один гейт www3.l.google.com. в том числе Youtube (трафик от которого я пропускать через VPN не хочу). Приходится использовать браузерное расширение специально для этих гугловых сервисов.
Эксперты по сетям может подскажут, можно ли как-то это ограничение обойти? Пока самое банальное что приходит в голову, это средствами IPTables перенаправлять весь трафик к гуглосервисам за исключением YouTube к VPN, но может есть решение покрасивее?
https://github.com/zapret-info/z-i/blob/master/dump.csv
?
То есть, если не 1-2 адреса, а всё, что как бы закрыто РКН?
Во-первых, с помощью директивы config можно инклудить один конфигурационный файл OpenVPN внутрь другого. Тогда вы сможете просто обновлять по крону этот инклуд, не беспокоясь об остальных настройках.
Во-вторых, можно поместить эти настройки в client config directory. Если у вас не используются индивидуальные настройки клиентов, то можно поместить список маршрутов в файл DEFAULT — он используется когда для клиента нет индивидуальных настроек. Если же они есть, то вроде бы можно также использовать директиву config, чтобы заинклудить файл DEFAULT в настройки для клиента.
Плюс в том, что при изменении ccd не требуется перезапуск сервера. Хотя я не уверен что сервер сам отправит новые маршруты уже подключенным клиентам — но в этом случае можно сделать перезапуск, или просто послать ему SIGHUP.
--client-config-dir dir
Specify a directory dir for custom client config files. After a connecting client has been authenticated, OpenVPN will look in this directory for a file having the same name as the client's X509 common name. If a matching file exists, it will be opened and parsed for client-specific configuration options. If no matching file is found, OpenVPN will instead try to open and parse a default file called «DEFAULT», which may be provided but is not required.
This file can specify a fixed IP address for a given client using --ifconfig-push, as well as fixed subnets owned by the client using --iroute.
One of the useful properties of this option is that it allows client configuration files to be conveniently created, edited, or removed while the server is live, without needing to restart the server.
The following options are legal in a client-specific context: --push, --push-reset, --iroute, --ifconfig-push, and --config.
Я добиваюсь схожего эффекта с помощью Proxy Auto Config.
VPN всегда подключён (и на сервере также крутится прокси и свой DNS-сервер). По крону генерируется PAC-файл, который раздается внутрь VPN-сети. PAC настроен так, чтобы направлять блокированные домены/IP через поднятый прокси.
Такое решение несколько проще чем добавление нескольких десятков-сотен маршрутов, но имеет недостаток.
Для автоматического обхода клиентский софт должен уметь PAC — читай, работает только с браузерами. Ручной обход требует всего лишь поддержки прокси, но настройки на клиенте все равно требуются.
Была мысль об использовании iptables (а точнее расширения ipset). Но опять же, это надо вбивать на клиенте VPN (комп или роутер).
А вот ваш подход интересен тем, что позволяет держать все настройки обхода на сервере, что очень и очень удобно!
Дополнительно, можно отроутить весь трафик TCP:53/UDP:53 через VPN, а не только гуглоднс — на тот случай если какой-то софт резолвит адреса сам. Хоть это и редкость, я полагаю.
-A PREROUTING -j PROXYNAMED
-A PROXYNAMED -d 127.0.0.1/32 -i br0 -p udp -m udp --dport 53 -j RETURN
-A PROXYNAMED -d 127.0.0.1/32 -i br0 -p tcp -m tcp --dport 53 -j RETURN
-A PROXYNAMED -i br0 -p udp -m udp --dport 53 -j DNAT --to-destination 127.0.0.1:53
-A PROXYNAMED -i br0 -p tcp -m tcp --dport 53 -j DNAT --to-destination 127.0.0.1:53
Где br0 — клиентский интерфейс, а на 53 порту локалхоста висит свой dns-сервер. Любой ns запрос на любой адрес будет направлен в него, а тот решит откуда его резолвить — с ns провайдера, с 8.8.8.8 или еще откуда.
* У хоста может быть несколько A-записей и их потребуется все добавить (этот вариант проскакивал в комментариях и он особых проблем не вызывает);
* DNS-сервер в зависимости от нагрузки/региона/настроения админа может выдавать разные адреса на один хост. Здесь иногда спасает добавление подсетей, но не всегда. Сегодня может выдать адрес 1.2.3.4, завтра — 4.3.2.1;
* Самый неприятный случай: ресурсы на одной и той же странице могут быть с разных ресурсов. Например, какой-нибудь видео-сервис (youtube, к примеру), где html — с одних серверов, картинки (или еще какая статика) — с других, и, наконец, видео — с третьих (каждый раз разных). Один раз наткнулся на ресурс, где на сервер, отдающий видео-контент, передавался ip-адрес, закодированный в url в base64. В итоге, веб-сервис видел мой vpn ip, а видео-сервис — мой прямой ip. Т.к. ip не совпадали, то видео-сервис показывал что-то вроде ошибки 403 и я довольствовался работающим сайтом, но не работающим видео. Пока инспектором не вытащил все адреса, к которым идут обращения, сайт нормально работать не мог. А если для каждого из ресурсов повторяется ситуация 1 или (что еще хуже) 2, то тут уж лучше весь траф направлять через vpn.
И оценочно, сколько маршрутов у вас получается?
Как на счет пойти от обратного, сделать так, чтобы часть прикладного софта в системе ходила через vpn?
То есть, на пальцах — два инстанса хрома, с разными user-data-dir, первый ходит через gw вашего провайдера, у второго default gw — это интерфейс vpn'a.
Можно же, без использования проксей в принципе, любое приложение зарулить на любой интерфейс, разделив таким образом их области применения.
Конкретно у меня так эти два хрома и работают, один в корп.сетке, через офисный роутер — для работы на работе, второй — через домашний впн, для втентаклей и ютубов.
Повторюсь, это работа не через прокси, а с помощью линуксовых namespace'ов.
«Ой, заблокировали, надо открыть в другом хроме.»
«Ой, тормозит, надо бы попробовать в первом хроме, может уже разблокировали.»
Когда хочешь открыть сайт, а видишь фигу (заглушку), потому что в очередной раз CDN улетел под блокировку — это пусть немного, но выбивает из колеи.
А в предлагаемом случае всё просто работает, пусть и немного медленнее для некоторых сайтов.
Я полагаю, когда дело дойдет до блокировки IM-сервисов, ваш подход будет результативнее. Тем более что почти все они умеют работать через прокси, так что всё сведется к настройкам IM-клиента.
Но в конечном итоге, на вкус и цвет.
Сделал у них разные цвет. схемы, привык за день.
Единственная история была написать скрипт-автоконфигуратор для openvpn, автоматом создающий неймспейсы, и прокидывабщий в них vpn интерфейс. Сделал, работает как часы, вообще никаких проблем.
Как обойти блокировки сайтов, не направляя весь трафик через VPN