Pull to refresh

Comments 42

О, боги! Неужели это самый «легкий для далеких от ИТ личностей способ»?
Чем для обхода блокировок не устраивает тор-браузер? Ставится «из коробки», скорость приемлемая, если видяшки не гонять. Ну и если гоняем всё (почти всё) «через зарубеж», то бонусом получаем минус десять к мыслям о КГБ-шной прослушке.
О, боги! Неужели это самый «легкий для далеких от ИТ личностей способ»?

По-моему очевидно что под «далекими от ИТ людьми» подразумеваются те, кто будет пользоваться этой схемой, а не те, кто ее будет настраивать. Для них просто все будет работать как до блокировок, никаких TOR не надо.
Само собой. Но всё равно это не «сделал и забыл». Могут быть разные ситуации: у людей сгорел роутер, заменили на новый — не работает (а в вашем случае ещё и обретение доступа к новому роутеру из-за границы может добавить веселья), забыли оплатить VPS — не работает, и т.д. И я не понимаю, какие преимущества это даёт по сравнению с тем же тор-браузером (кроме скорости) или прокси-включающим расширением браузера или ещё чем-то подобным. Хотя такие глубины админства впечатляют.
у людей сгорел роутер, заменили на новый — не работает (а в вашем случае ещё и обретение доступа к новому роутеру из-за границы может добавить веселья)
Это настолько редкое явление что я его не рассматриваю. За многие годы такое происходило может быть раз. Ну и получить доступ удаленно проблем никаких в наше время нет.

И я не понимаю, какие преимущества это даёт по сравнению с тем же тор-браузером (кроме скорости)

Главное преимущество — что об этом не нужно думать. А не вспоминать что чтобы зайти туда-то мне нужно лезть через Тор.
UFO just landed and posted this here

Есть множество решений при которых у пользователей все будет работать прозрачно. А вот эффективность и сложность настройки/поддержки у всех разная.
Вот, к примеру, чем ваше решение лучше использования dnsmasq и ipset, как это описано тут? Кстати последняя версия unbound тоже умеет работать с ipset.

Вот, к примеру, чем ваше решение лучше использования dnsmasq и ipset, как это описано тут?

Как минимум тем, что от клиентского роутера почти ничего не нужно, кроме поддержки BGP и какого-либо VPN. Во все это любой копеечный микротик нынче умеет. А в решении с ipset всё ложится на локальный клиентский роутер.


Еще там нет никакого housekeeping-а списка — домен резолвится, все IP пихаются в ipset — и остаются там навечно. Потенциально их может быть много. И если домен прыгает по IP, старые IP все равно будут ходить в TOR пока роутер не ребутнешь.


А в остальном всё примерно аналогично, да.

Для таких людей как раз самым простым способом будет оплата PIA или ProtonVPN (последний, кстати, вообще бесплатен).
Супер сложно. Я для VPN антизапрета написал специальный DNS-резолвер, который:
  1. Запрашивает A-записи домена у рекурсивного резолвера
  2. Получив ответ, устанавливает соответствие настоящим IP-адресам в большой внутренней приватной подсети (iptables … -d 10.224.0.1 -j DNAT --to 1.2.3.4)
  3. Отдаёт запросившему клиенту внутренний IP-адрес.

У такого подхода есть множество преимуществ:

  • Клиенту устанавливается только один или несколько маршрутов, вместо десятков тысяч маршрутов;
  • Маршрутизируются только заблокированные домены, а не все сайты на заблокированном IP-адресе;
  • Возможность обновления списка заблокированных сайтов без переподключения клиента;
  • Корректная работа с доменами, постоянно меняющими IP-адреса, и с CDN-сервисами;
  • Корректная работа с провайдерами, блокирующими все поддомены заблокированного домена (блокировка всей DNS-зоны). Пример такого провайдера — Yota.


Но есть и минусы:

  • Необходимо использовать только DNS-сервер внутри VPN. С другими DNS-серверами работать не будет.
  • Работает только для заблокированных доменов и программ, использующих доменные имена. Для заблокированных IP-адресов необходимо использовать обычную маршрутизацию.


Перед резолвером стоит кэширующий knot-resolver, который перенаправляет запросы на этот резолвер только для заблокированных доменных зон. В принципе, можно всё реализовать средствами самого knot-resolver или powerdns, когда-нибудь перепишу и выложу.
Клиенту устанавливается только один или несколько маршрутов, вместо десятков тысяч маршрутов
Тут все ровно так же. Сотня тысяч маршрутов только для IP-блокировок, иначе никак. А для доменов маршруты добавляются по факту запроса конкретного домена.

Маршрутизируются только заблокированные домены, а не все сайты на заблокированном IP-адресе
Да, это хорошо, но с моей точки зрения несущественно. Если какая-то часть доменов на том же IP пойдет тоже через VPN — ну и пусть.

Возможность обновления списка заблокированных сайтов без переподключения клиента
Тут не понял. Что такое «переподключение клиента»? У меня список обновляет по крону в фоне на сервере и клиенты там никак не участвуют.

Корректная работа с доменами, постоянно меняющими IP-адреса, и с CDN-сервисами
Не вижу проблем с этим в моей схеме. Если TTL в DNS протух и домен отрезолвился в новый IP — маршрут до него будет добавлен. Старый IP протухнет со временем. Эту схему можно, конечно, немного улучшить активно убивая старые IP, но если там Round-Robin DNS с низким TTL то IP будут постоянно добавляться-удаляться.

Корректная работа с провайдерами, блокирующими все поддомены заблокированного домена (блокировка всей DNS-зоны). Пример такого провайдера — Yota
У меня этот кейс тоже срабатывает и даже описан в статье.
В вашем подходе требуется настройка BGP на клиентском оборудовании, в моём — нет. VPN антизапрета работает на компьютерах, телефонах и маршрутизаторах без каких-либо дополнительных настроек.

Тут все ровно так же. Сотня тысяч маршрутов только для IP-блокировок, иначе никак.
А на антизапрете — пара десятков маршрутов (большой внутренний диапазон и самые крупные заблокированные диапазоны).
А на антизапрете — пара десятков маршрутов (большой внутренний диапазон и самые крупные заблокированные диапазоны).

Каким образом обеспечивается доступ к хостам, заблокированным по IP? Тот же телеграм и ко. Как абстрактное клиентское устройство с OpenVPN клиентом должно понять что ему нужно отправлять траффик в VPN, а не напрямую?

Тут либо пушить маршруты (пусть и суммаризованные) клиенту через OpenVPN, либо пускать весь траффик через VPN.
На данный момент — никак, но реализовать это просто: если в DNS-ответе есть A-запись на заблокированный IP-адрес, то ему тоже нужно установить соответствие, а клиенту отдать адрес из внутреннего диапазона.

Тут есть недостаток в том, что это будет работать только если клиент обращается по хостнейму. При прямом подключении к IP уже ой. Не уверен что это часто происходит, но тем не менее.


Но тут для мобильных клиентов, конечно, без вариантов. Пушить 100к маршрутов через OpenVPN чтобы покрыть 0.1% юзкейсов так себе идея :)


А для домашних роутеров современных эти маршруты не проблема ни разу.

Можно немного дополнить Вашу схему, устранив ряд минусов.
Мобильные клиенты могут быть Road warrior'ами через туннель до хорошего такого гейта поблизости, которому не сложно переварить и миллион BGP-маршрутов. Даже не особо приходится заморачиваться с тем, чтобы какой-нибудь IPSec c IKEv2 был всегда включен на мобильном клиенте. Да, оверхед на лишний туннель, но если туннель заворачивается в UDP, он небольшой, да и дополнительный слой безопасности для мобильного устройства не помешает.
Там же, рядом с гейтом (в границах своей сети поблизости), лучше и размещать Unbound: быстрее будет отрабатывать bgp-tap. Не могу ручаться, где скорость работы самого DNS будет больше, при DNS-over-TLS Unbound или при маршрутизации обычного DNS-трафика через туннель до заграницы, но практика показывает, что первый вариант работает достаточно быстро и стабильно. Еще и не придется заморачиваться с неймспейсом, так как второй Bird можно будет поднять там же и обрабатывать его префиксы отдельно от тех, что присылает Bird с VPS. Минус — в необходимости наличия еще одного устройства кроме роутера, но подойдут и совсем недорогие типа RPi.
Как абстрактное клиентское устройство с OpenVPN клиентом должно понять что ему нужно отправлять траффик в VPN, а не напрямую?


Клиент подключается к VPN. VPN-сервер ему устанавливает маршрут 10.224.0.1/16 и DNS-сервер внутри VPN.

Клиент запрашивает rutracker.org.
image
Клиент маршрутизирует трафик в VPN, потому что у него установлен маршрут 10.224.0.1/16.
Для незаблокированных сайтов DNS-сервер отдаёт настоящие IP-адреса, и трафик не маршрутизируется в VPN.

Про домены то понятно, я имел в виду IP блокировки.

Аналогично — если в DNS-ответе незаблокированного домена A-запись указывает на заблокированный IP-адрес, то тоже устанавливаем ему соответствие и отдаём клиенту адрес из внутренней сети.
Такой подход не сработает при обращении к IP-адресу напрямую, не через DNS, но такие случаи редки.
UFO just landed and posted this here
Но не очень, когда весь DNS приходится гнать по vpn на 5-баксовый сервер без sla

Да вроде не мешает ни разу. DNS траффик копеечный, пинг около 50мс, ответы кешируются. Я поднял два VPS в разных местах Европы и если один падает второй возьмет бразды правления — на клиентах задан BGP preference чтобы один из них был приоритетнее.


А не думали пускать трафик через VPN только в том случае, когда от провайдера приходит явный признак блока (характерная страница или отсутствие ответа)?

Алгоритм детектирования этого дела довольно сложный думается, поэтому проще сделать кучу маршрутов. Тем более что эти ничем не напрягает оборудование особо. По крайней мере мои ARM-роутеры с OpenWRT 100-200к маршрутов даже не замечают.

Вот ещё бы найти хостера, который разрешает VPN. А то сейчас чуть не у всех, даже иностранных, хостеров в лицензионном соглашении прописан запрет поднимать прокси/VPN.

Ну, мало ли что там написано :) Я использую несколько разных VPS-провайдеров, никто пока не жаловался. На одном даже выходная нода TOR висит, абузы сыпятся, отвечаю что TOR, провайдера устраивает.

Дело полезное, но не боитесь, что IP будет на некоторых ресурсах заблокирован (полностью или частично), и использование VPN превратится в боль?

Само собой боюсь :) Поэтому VPN у меня через другие VPS, где Tor только скрытым бриджом есть.

Думаю, что если прокси не распространять для всех, то провайдер может и не обращать внимание на то, что там используется VPN или еще что-то.
Запрет кстати прописывается на публичные VPN (не для частного использования).
попадает, в том числе, youtube.com и его CDNы.

Но ютуб не блокируют по IP, его блочат при помощи DPI (тип блокировки по URL), следовательно, для обхода блокировки достаточно обмануть DPI.

Ютуб никак не блочат т.к. он наглухо в HTTPS и доступа к URL нет ни у какого DPI. Поэтому его можно просто использовать без VPN.

Ой, забыл, что подход у них избирательный, и хотя ютуб уже давно в выгрузке, его не блокируют. Вообще, должны блокировать домен целиком, если HTTPS.

Неужели BGP настраивается проще чем OSPF или вообще какой-нибудь RIP?

Минимальная конфигурация, как мне кажется, даже проще чем OSPF — не нужны никакие area и прочее. Ну и BGP работает по TCP и можно пириться хоть через полмира даже без тоннелей, если необходимо. А OSPF более капризный — мультикаст ему подавай...


Я использую оба, у каждого протокола свое применение — BGP больше EGP, а OSPF — в основном IGP.

Да, проще.


OSPF хочет мультикасты, в BGP прописываем пиров и всё.


А ещё в BGP можно легко менять next-hop для анонсируемях маршрутов и это заложено в протокол by design всеми производителями софта/оборудования с поддержкой BGP (bgp peer не обязан быть гейтвеем), а вот про тот же OSPF есть сомнения (хотя могу и ошибаться).

Бороться таким способом с РКН все-равно что играть на приставке пока батя на заводе.
Tor не во всех организациях разрешен. Самый выгодный вариант — купить линуховую vps, напр. за 5$ в azure и гонять траффик через нее.
А имеет ли смысл сейчас делать разделение по доменам, если в браузерах вот-вот будет DoH?
Я гоню всё через заграничный VPS с помощью прозрачного socks-прокси на shadowsocks.

А как связан DoH с тем что блокируется провайдерам?


DoH не позволит им юзать перехват DNS для подсовывания своих блокстраничек вместо правильного IP и все.


В итоге будут бить по площадям, ай ай ай от Ревизора то никто не хочет получить.


Я гоню всё через заграничный VPS с помощью прозрачного socks-прокси на shadowsocks.

Я писал что можно, конечно, гнать все через забугор, но не хочется.
Например тот же Вконтакт через который многие музычку слушают, блокирует почти всю ее с зарубежных адресов.

Необходимо еще внедрение eSNI.
unbound + python module и этого хватит.

Да, можно и так, вариантов много.
Но с DNSTap ты не привязан к одному DNS серверу.

Так что было решено придумать легкий для далеких от ИТ личностей способ обхода блокировок, желательно вовсе без их участия.


Не сказал бы, что данный способ легкий, особенно для далеких от IT личностей, учитывая, что здесь нет пошаговых инструкци.
Я просто к тому, что есть действительно более простой способ, который даже я — реально далекий от сетевых технологий человек — смог освоить.
Sign up to leave a comment.

Articles