Comments 42
Чем для обхода блокировок не устраивает тор-браузер? Ставится «из коробки», скорость приемлемая, если видяшки не гонять. Ну и если гоняем всё (почти всё) «через зарубеж», то бонусом получаем минус десять к мыслям о КГБ-шной прослушке.
О, боги! Неужели это самый «легкий для далеких от ИТ личностей способ»?
По-моему очевидно что под «далекими от ИТ людьми» подразумеваются те, кто будет пользоваться этой схемой, а не те, кто ее будет настраивать. Для них просто все будет работать как до блокировок, никаких TOR не надо.
у людей сгорел роутер, заменили на новый — не работает (а в вашем случае ещё и обретение доступа к новому роутеру из-за границы может добавить веселья)Это настолько редкое явление что я его не рассматриваю. За многие годы такое происходило может быть раз. Ну и получить доступ удаленно проблем никаких в наше время нет.
И я не понимаю, какие преимущества это даёт по сравнению с тем же тор-браузером (кроме скорости)
Главное преимущество — что об этом не нужно думать. А не вспоминать что чтобы зайти туда-то мне нужно лезть через Тор.
Есть множество решений при которых у пользователей все будет работать прозрачно. А вот эффективность и сложность настройки/поддержки у всех разная.
Вот, к примеру, чем ваше решение лучше использования dnsmasq и ipset, как это описано тут? Кстати последняя версия unbound тоже умеет работать с ipset.
Вот, к примеру, чем ваше решение лучше использования dnsmasq и ipset, как это описано тут?
Как минимум тем, что от клиентского роутера почти ничего не нужно, кроме поддержки BGP и какого-либо VPN. Во все это любой копеечный микротик нынче умеет. А в решении с ipset всё ложится на локальный клиентский роутер.
Еще там нет никакого housekeeping-а списка — домен резолвится, все IP пихаются в ipset — и остаются там навечно. Потенциально их может быть много. И если домен прыгает по IP, старые IP все равно будут ходить в TOR пока роутер не ребутнешь.
А в остальном всё примерно аналогично, да.
- Запрашивает A-записи домена у рекурсивного резолвера
- Получив ответ, устанавливает соответствие настоящим IP-адресам в большой внутренней приватной подсети (
iptables … -d 10.224.0.1 -j DNAT --to 1.2.3.4) - Отдаёт запросившему клиенту внутренний 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У меня этот кейс тоже срабатывает и даже описан в статье.
Тут все ровно так же. Сотня тысяч маршрутов только для IP-блокировок, иначе никак.А на антизапрете — пара десятков маршрутов (большой внутренний диапазон и самые крупные заблокированные диапазоны).
А на антизапрете — пара десятков маршрутов (большой внутренний диапазон и самые крупные заблокированные диапазоны).
Каким образом обеспечивается доступ к хостам, заблокированным по IP? Тот же телеграм и ко. Как абстрактное клиентское устройство с OpenVPN клиентом должно понять что ему нужно отправлять траффик в VPN, а не напрямую?
Тут либо пушить маршруты (пусть и суммаризованные) клиенту через OpenVPN, либо пускать весь траффик через VPN.
Тут есть недостаток в том, что это будет работать только если клиент обращается по хостнейму. При прямом подключении к 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.
Клиент маршрутизирует трафик в VPN, потому что у него установлен маршрут
10.224.0.1/16.Для незаблокированных сайтов DNS-сервер отдаёт настоящие IP-адреса, и трафик не маршрутизируется в VPN.
нет.
Но не очень, когда весь DNS приходится гнать по vpn на 5-баксовый сервер без sla
Да вроде не мешает ни разу. DNS траффик копеечный, пинг около 50мс, ответы кешируются. Я поднял два VPS в разных местах Европы и если один падает второй возьмет бразды правления — на клиентах задан BGP preference чтобы один из них был приоритетнее.
А не думали пускать трафик через VPN только в том случае, когда от провайдера приходит явный признак блока (характерная страница или отсутствие ответа)?
Алгоритм детектирования этого дела довольно сложный думается, поэтому проще сделать кучу маршрутов. Тем более что эти ничем не напрягает оборудование особо. По крайней мере мои ARM-роутеры с OpenWRT 100-200к маршрутов даже не замечают.
Ну, мало ли что там написано :) Я использую несколько разных VPS-провайдеров, никто пока не жаловался. На одном даже выходная нода TOR висит, абузы сыпятся, отвечаю что TOR, провайдера устраивает.
попадает, в том числе, youtube.com и его CDNы.
Но ютуб не блокируют по IP, его блочат при помощи DPI (тип блокировки по URL), следовательно, для обхода блокировки достаточно обмануть DPI.
Неужели 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 и гонять траффик через нее.
Я гоню всё через заграничный VPS с помощью прозрачного socks-прокси на shadowsocks.
А как связан DoH с тем что блокируется провайдерам?
DoH не позволит им юзать перехват DNS для подсовывания своих блокстраничек вместо правильного IP и все.
В итоге будут бить по площадям, ай ай ай от Ревизора то никто не хочет получить.
Я гоню всё через заграничный VPS с помощью прозрачного socks-прокси на shadowsocks.
Я писал что можно, конечно, гнать все через забугор, но не хочется.
Например тот же Вконтакт через который многие музычку слушают, блокирует почти всю ее с зарубежных адресов.
unbound + python module и этого хватит.
Так что было решено придумать легкий для далеких от ИТ личностей способ обхода блокировок, желательно вовсе без их участия.
Не сказал бы, что данный способ легкий, особенно для далеких от IT личностей, учитывая, что здесь нет пошаговых инструкци.
Обход блокировок РКН с помощью DNSTap и BGP