Comments 52
Как раз искал, как пустить через VPN только некоторые сайты. Спасибо за публикацию.
а можно все это делать по именам доменов а не ip адресам?
Для браузеров есть различные плагины, расширяющие возможности настроек прокси-серверов. Настраиваются прокси-сервера и в них заворачиваются только нужные домены.
<a href=«https://chrome.google.com/webstore/detail/frigate-cdn-smooth-access/mbacbcfdfaapbcnlnbmciiaakomhkbkb>friGate CDN один из них. Вроде как бесплатный. Блокировка по именам доменов, только указанные домены сайтов (есть список для Украины).
Я себе настроил немного наоборот: на своём VPN-сервере крутится OpenVPN, ничего не знающий о блокировках.
А в качестве клиента – роутер Микторик, на котором запущен скрипт, обходящий заданный список доменов, собирающий их IP-адреса и пускающий их через VPN.
У меня поднят обычный proxy-server на машине, у которой есть доступ к недоступным с домашней машины ресурсам. На домашней машине PAC (proxy auto configuration file) файл, в котором написано, куда ходить в случае какого запроса. Ну и естественно, если запрос включает в себя недоступные ресурсы — то браузер идет к прокси-серверу
У меня вместо VPN используется SOCKS over SSH, а в этот SOCKS proxy заворачиваются нужные домены стандартным способом через WPAD.
В принципе можно SOCKS proxy и за VPN расположить.
Самое сложное — найти, куда положить скрипт для WPAD.
В принципе можно 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 пускать! Что и описано в статье.
#Ключевой момент — прописываем маршруты на 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»
Проблема в том, что OpenVPN_as — позволяет завести только два бесплатных аккаунта, потому — лучше поднимать VPN самому. Да, это будет не одна консольная команда по запуску установочного скрипта, зато без ограничений.
И потом, VPN — это обычный сервис по собственной безопасности, в бесплатном ВайФай московского метро, в гостиницах и тп. Лучше весь трафик через него пропускать, меньше рисков нарваться на школоло-скрипткидди.
И потом, VPN — это обычный сервис по собственной безопасности, в бесплатном ВайФай московского метро, в гостиницах и тп. Лучше весь трафик через него пропускать, меньше рисков нарваться на школоло-скрипткидди.
согласен, это добавит безопасности, но может замедлить работу, тут уже каждый выбирает, что важнее
С помощью этого скрипта, можно быстро поднять OpenVPN.
А зачем он, если есть Pritunl?
10-30 минут, включая разворачивание хостинга и дичтрибутива, — и свой OpenVPN-сервер с web-панелью, неограниченным числом клиентов, "организаций", и т. д.,
Офис Яндекса.
Следственные мероприятия проводятся на основании статьи 111 Криминального кодекса Украины – «государственная измена». Виновным по данной статье грозит лишение свободы сроком на 12-15 лет с конфискацией имущества.
Следственные мероприятия проводятся на основании статьи 111 Криминального кодекса Украины – «государственная измена». Виновным по данной статье грозит лишение свободы сроком на 12-15 лет с конфискацией имущества.
Я использовал для подобного набор скриптов вот из этого репозитория:
https://bitbucket.org/ValdikSS/antizapret
Небольшая доработка напильником требуется. (он по-умолчанию настроен на github-репозиторий с дампом БД Роскомнадзора)
Естественно для этого необходим свой сервер...((
https://bitbucket.org/ValdikSS/antizapret
Небольшая доработка напильником требуется. (он по-умолчанию настроен на github-репозиторий с дампом БД Роскомнадзора)
Естественно для этого необходим свой сервер...((
Может, есть какая-то возможность отследить блокируемый сайт по ошибке 451, вместо того чтобы вручную их все прописывать?
А я вообще если нужно хожу через Удаленный рабочий стол Amazon AWS EC2
Обхожу блокировки с помощью простовпн (1$/мес) прописывая маршруты до нужных сайтов (dockerhub/linkedin/bitbucket/...) на VPN, находясь в Крыму.
Однако побороть блокировку сервисов google (developers/cloud/issuetracker/...) я не смог, так как google все свои сервисы пропускает через один гейт www3.l.google.com. в том числе Youtube (трафик от которого я пропускать через VPN не хочу). Приходится использовать браузерное расширение специально для этих гугловых сервисов.
Эксперты по сетям может подскажут, можно ли как-то это ограничение обойти? Пока самое банальное что приходит в голову, это средствами IPTables перенаправлять весь трафик к гуглосервисам за исключением YouTube к VPN, но может есть решение покрасивее?
Однако побороть блокировку сервисов google (developers/cloud/issuetracker/...) я не смог, так как google все свои сервисы пропускает через один гейт www3.l.google.com. в том числе Youtube (трафик от которого я пропускать через VPN не хочу). Приходится использовать браузерное расширение специально для этих гугловых сервисов.
Эксперты по сетям может подскажут, можно ли как-то это ограничение обойти? Пока самое банальное что приходит в голову, это средствами IPTables перенаправлять весь трафик к гуглосервисам за исключением YouTube к VPN, но может есть решение покрасивее?
А если это VK или Яндекс? Как узнать все IP адреса для этих сетей?
Ему плохо не станет, если пропихнуть все маршруты, например, отсюда:
https://github.com/zapret-info/z-i/blob/master/dump.csv
?
То есть, если не 1-2 адреса, а всё, что как бы закрыто РКН?
https://github.com/zapret-info/z-i/blob/master/dump.csv
?
То есть, если не 1-2 адреса, а всё, что как бы закрыто РКН?
Внес правки в /etc/openvpn/server.conf, подключился, начали плохо грузится сайты (наверно из-за того, что не все ip заблокированных сайтов добавил), даже те, которые не заблокированы. После убрал изменения в этом файле и vpn вообще перестал работать. Что не так?
Shadowsocks — прост, эффективен, стабилен. Сделан китайцами для обхода Щита.
Небольшой совет!
Во-первых, с помощью директивы config можно инклудить один конфигурационный файл OpenVPN внутрь другого. Тогда вы сможете просто обновлять по крону этот инклуд, не беспокоясь об остальных настройках.
Во-вторых, можно поместить эти настройки в client config directory. Если у вас не используются индивидуальные настройки клиентов, то можно поместить список маршрутов в файл DEFAULT — он используется когда для клиента нет индивидуальных настроек. Если же они есть, то вроде бы можно также использовать директиву config, чтобы заинклудить файл DEFAULT в настройки для клиента.
Плюс в том, что при изменении ccd не требуется перезапуск сервера. Хотя я не уверен что сервер сам отправит новые маршруты уже подключенным клиентам — но в этом случае можно сделать перезапуск, или просто послать ему SIGHUP.
Я добиваюсь схожего эффекта с помощью Proxy Auto Config.
VPN всегда подключён (и на сервере также крутится прокси и свой DNS-сервер). По крону генерируется PAC-файл, который раздается внутрь VPN-сети. PAC настроен так, чтобы направлять блокированные домены/IP через поднятый прокси.
Такое решение несколько проще чем добавление нескольких десятков-сотен маршрутов, но имеет недостаток.
Для автоматического обхода клиентский софт должен уметь PAC — читай, работает только с браузерами. Ручной обход требует всего лишь поддержки прокси, но настройки на клиенте все равно требуются.
Была мысль об использовании iptables (а точнее расширения ipset). Но опять же, это надо вбивать на клиенте VPN (комп или роутер).
А вот ваш подход интересен тем, что позволяет держать все настройки обхода на сервере, что очень и очень удобно!
Дополнительно, можно отроутить весь трафик TCP:53/UDP:53 через VPN, а не только гуглоднс — на тот случай если какой-то софт резолвит адреса сам. Хоть это и редкость, я полагаю.
Во-первых, с помощью директивы config можно инклудить один конфигурационный файл OpenVPN внутрь другого. Тогда вы сможете просто обновлять по крону этот инклуд, не беспокоясь об остальных настройках.
Во-вторых, можно поместить эти настройки в client config directory. Если у вас не используются индивидуальные настройки клиентов, то можно поместить список маршрутов в файл DEFAULT — он используется когда для клиента нет индивидуальных настроек. Если же они есть, то вроде бы можно также использовать директиву config, чтобы заинклудить файл DEFAULT в настройки для клиента.
Плюс в том, что при изменении ccd не требуется перезапуск сервера. Хотя я не уверен что сервер сам отправит новые маршруты уже подключенным клиентам — но в этом случае можно сделать перезапуск, или просто послать ему SIGHUP.
Цитата из man openvpn
--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, а не только гуглоднс — на тот случай если какой-то софт резолвит адреса сам. Хоть это и редкость, я полагаю.
Спасибо, полезное дополнение!
На этот случай пользуюсь такими правилами:
Где br0 — клиентский интерфейс, а на 53 порту локалхоста висит свой dns-сервер. Любой ns запрос на любой адрес будет направлен в него, а тот решит откуда его резолвить — с ns провайдера, с 8.8.8.8 или еще откуда.
-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 или еще откуда.
Пользуюсь openvpn с подобным анонсированием уже долгое время. За все время использования помимо описанных преимуществ есть очевидные недостатки:
* У хоста может быть несколько A-записей и их потребуется все добавить (этот вариант проскакивал в комментариях и он особых проблем не вызывает);
* DNS-сервер в зависимости от нагрузки/региона/настроения админа может выдавать разные адреса на один хост. Здесь иногда спасает добавление подсетей, но не всегда. Сегодня может выдать адрес 1.2.3.4, завтра — 4.3.2.1;
* Самый неприятный случай: ресурсы на одной и той же странице могут быть с разных ресурсов. Например, какой-нибудь видео-сервис (youtube, к примеру), где html — с одних серверов, картинки (или еще какая статика) — с других, и, наконец, видео — с третьих (каждый раз разных). Один раз наткнулся на ресурс, где на сервер, отдающий видео-контент, передавался ip-адрес, закодированный в url в base64. В итоге, веб-сервис видел мой vpn ip, а видео-сервис — мой прямой ip. Т.к. ip не совпадали, то видео-сервис показывал что-то вроде ошибки 403 и я довольствовался работающим сайтом, но не работающим видео. Пока инспектором не вытащил все адреса, к которым идут обращения, сайт нормально работать не мог. А если для каждого из ресурсов повторяется ситуация 1 или (что еще хуже) 2, то тут уж лучше весь траф направлять через vpn.
* У хоста может быть несколько 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'ов.
Как на счет пойти от обратного, сделать так, чтобы часть прикладного софта в системе ходила через vpn?
То есть, на пальцах — два инстанса хрома, с разными user-data-dir, первый ходит через gw вашего провайдера, у второго default gw — это интерфейс vpn'a.
Можно же, без использования проксей в принципе, любое приложение зарулить на любой интерфейс, разделив таким образом их области применения.
Конкретно у меня так эти два хрома и работают, один в корп.сетке, через офисный роутер — для работы на работе, второй — через домашний впн, для втентаклей и ютубов.
Повторюсь, это работа не через прокси, а с помощью линуксовых namespace'ов.
Боюсь, как раз ваша идея — «перманентный головняк».
«Ой, заблокировали, надо открыть в другом хроме.»
«Ой, тормозит, надо бы попробовать в первом хроме, может уже разблокировали.»
Когда хочешь открыть сайт, а видишь фигу (заглушку), потому что в очередной раз CDN улетел под блокировку — это пусть немного, но выбивает из колеи.
А в предлагаемом случае всё просто работает, пусть и немного медленнее для некоторых сайтов.
Я полагаю, когда дело дойдет до блокировки IM-сервисов, ваш подход будет результативнее. Тем более что почти все они умеют работать через прокси, так что всё сведется к настройкам IM-клиента.
Но в конечном итоге, на вкус и цвет.
«Ой, заблокировали, надо открыть в другом хроме.»
«Ой, тормозит, надо бы попробовать в первом хроме, может уже разблокировали.»
Когда хочешь открыть сайт, а видишь фигу (заглушку), потому что в очередной раз CDN улетел под блокировку — это пусть немного, но выбивает из колеи.
А в предлагаемом случае всё просто работает, пусть и немного медленнее для некоторых сайтов.
Я полагаю, когда дело дойдет до блокировки IM-сервисов, ваш подход будет результативнее. Тем более что почти все они умеют работать через прокси, так что всё сведется к настройкам IM-клиента.
Но в конечном итоге, на вкус и цвет.
Ну фиг знает, вести реестр заблокированных ресурсов, постоянно актуализируя таблицу маршрутизации, либо перещелкиваться с одного окна на другое, что проще и удобней?
Сделал у них разные цвет. схемы, привык за день.
Единственная история была написать скрипт-автоконфигуратор для openvpn, автоматом создающий неймспейсы, и прокидывабщий в них vpn интерфейс. Сделал, работает как часы, вообще никаких проблем.
Сделал у них разные цвет. схемы, привык за день.
Единственная история была написать скрипт-автоконфигуратор для openvpn, автоматом создающий неймспейсы, и прокидывабщий в них vpn интерфейс. Сделал, работает как часы, вообще никаких проблем.
Напишите, пожалуйста, кто знает, как можно то же самое сделать на EdgeOS (Ubiquity EdgeRouter X)?
Sign up to leave a comment.
Как обойти блокировки сайтов, не направляя весь трафик через VPN