Зачем людям ранее был нужен VPN (кроме мошенников конечно)? Чтоб ходить на Linkedin и обходить всякие разные запреты РКН.
Когда ввели санкции и некоторые сайты перекрасились в сине-желтый цвет, то многие по старой памяти подумали - включим VPN и всё сразу станет как раньше, разве что русские сайты начнут открываться на 50мс медленнее.
Но не тут-то было. Вместе с перекраской сайтов, началась волна DDoS и хакерских атак на различные сервисы в РФ. В итоге, российские сайты закрылись от остального интернета. И с VPN стало очень некомфортно - хочешь пользоваться Terraform или, там, MatterMost скачать - включаешь VPN... И... сразу же не можешь сходить ни на Ozon ни на Госуслуги.
Интернет разделился на InnerNet и OuterNet.
Различные (удачные и не очень) попытки.
Сама собой возникла потребность более умного VPN, который русские сайты отправит по одному маршруту, а не-русские - по другому.
Сделать это можно различными способами.
Первый, который пришел в голову - это конечно же старый добрый squid: ставим два хоста, соединяем тоннелем. На первом хосте, ставим второй апстримом для определенных доменных зон или доменов, настраиваем SSL-BUMP.
Однако такое решение, хоть оно и достаточно эффективное, имеет определенные минусы :
Нужно везде прописывать проксю. Когда мы делаем не поделку, а решение - это плохо.
Нужно везде грузить сертификаты CA. И если в браузере это +- несложно, то, например, в различных продуктах от JetBrains - их нужно прописывать отдельно. В общем, чтоб завернуть весь трафик из дома или из офиса - нужно СЛИШКОМ МНОГО движений.
Ну и заявлять всем : "ребята, я вам сделал удобно, но учтите, что теперь я имею возможность читать весь ваш трафик, переписку и сайты с порнухой" - настолько не очень, что люди не будут пользоваться, или будут так же включать - от случая к случаю. А хочется - set and forget.
Второй вариант - SNI (как, например, работает DPI) - в SSL трафике хостнейм передается (всё реже и реже) открыто. Но, в TLS 1.3 это уже не актуально. Да и в целом - анализировать весь трафик слишком накладно.
В итоге - остаются только айпишки. С ними я и начал работать (после того, как полностью поднял инфру на SQUID + генерацию CA :) )
Получился...
Гео-роутинг.
В принципе зароутить трафик не сложно :
Между входящим ВПН-сервером и второй его головой настраивается тоннель. Настраиваем PBR - то, что пометили в mangle - отправляем на вторую голову. То, что не пометили - выпускаем. Входящий ставим в РФ, второй - там, где остальной мир не будет вас блочить.
Первый этап так же не сложен - распаковываем базу GEOIP и все подсетки, которые находятся в гео RU - помечаем для выпуска сразу. Однако, не подсетками едиными (тут я как раз столкнулся с Ozon) - некоторые русские сервисы хостятся не в РФ (а, например, в Германии), при этом, пускают только русских. Для таких нужен отдельный список и котел в аду за кроссбординг ПД. А еще, мейнтейнить список айпишек несколько неудобно, особенно, если учесть, что айпишки у сайта могут меняться без предупреждения (потому, что часть Озона за клаудфларой).
Когда браузер обращается к сайту, он вначале резолвит имя в айпишник. Выход напросился сам собой : перехватываем DNS-запрос, если он к нужному сайту или нужной зоне - добавляем айпишник в iptables. Причем, в отличие от решения с SNI - мы успеем добавить айпишник еще до соединения браузера с сайтом. Главное делать это быстро : секунда-две на каждый запрос к ресурсу в пост-модемные времена - непозволительно долго.
Здесь мне помог PowerDNS - отличное решение, которое позволяет делать пост-обработку ответов DNS через LUA :
Ловим каждый запрос.
Отправляем по вебсокету демону на питоне.
Демон принимает решение и настраивает IPT.
Конечно, помня, что в DNS есть еще и CNAMEs, простейшим алгоритмом не обойтись - приходится строить цепочки записей и обходить их как слева направо, так и справа налево. Тем не менее работает достаточно эффективно - в пределе, на самой дешевой яндексовской виртуалке, обработка DNS-запроса занимает 100мс. А обычно, укладываемся в несколько мс.
В отдельных случаях, при холодном старте, всё-таки не всегда успевает добавить в IPT для отдельных сайтов. Поэтому, тот же озон при холодном старте инфраструктуры, на первое обращение часто отдает 403. Чистка кеша на клиенте и последующий релоад страницы приводит роутинг в чувства.
NFTables.
Изначально, я хотел использовать NFTables - я их очень люблю, и они в целом эффективнее чем iptables/netfilter. Позволяют творить такое, что IPT/NF даже не снилось. Но, не тут-то было. Большой набор рул в nft не загрузить потому, что nft работает через RT_NETLINK так, что туда много не влезает. В аутернетах есть бенчи, которые показывают, что nft весьма медленно добавляет рулы по сравнению с IPT/NF.
Итог.
В итоге, получился MRVPN, который можно скачать отсюда : https://github.com/AlexMKX/mrvpn
Деплой осуществляется через ansible role, что современно модно и молодежно.
Для клиентов используется FireZone - один из лучших фронтов для WireGuard, который поддерживает гугловый SAML (а в коммерческой версии и другие), что важно для корпов.
Комментарии (117)
poxvuibr
29.05.2022 16:16+4Это круто, конечно! Год назад где-то мне бы очень помогло что-то, что роутит запросы не по айпи, а по символьному имени. То есть всё, в чём есть, например, слово youtube, нужно направлять в vpn, а всё, где его нет, мимо vpn. Да и сейчас это мне пригодится. Я так понимаю mrvpn либо это уже может, либо надо только совсем немного поправить код. Бурные апплодисменты!
У меня ещё есть пара вопросов, прямого отношения к делу не имеющих. Насколько я понимаю ваше решение поднимает несколько докер-контейнеров, в одном из которых сервис на питоне.
Прежде всего хочу спросить почему именно Питон. Без намерения критиковать, просто собираю причины, которыми люди руководствуются, когда выбирают язык.
Ещё интересно, почему именно веб-сокеты. Почему не обыкновенные сокеты (не знаю, как их правильно назвать )) ) или не unix domain sockets?
И, наконец, как я понимаю, докер выбран для удобства развёртывания? Впринципе ничего же не мешает всё это поднять локально без контейнеров?
AlexKMK Автор
29.05.2022 16:51+9Нетипичный хабр - комментаторы задают интересные вопросы ????????????
Да, mrvpn именно это и делает - есть вайтлист регулярок доменов. Все, что в вайтлисте - идёт без впн. Что не в вайтлисте - идёт в ВПН. Если речь идёт об отправке в ВПН одного домена и всё - нужно страны убрать из настроек и оставить только регулярку для етуба с negative match.
С питоном все просто - опыт и любовь после 20+ лет с++, ассемблера и других языков типа PHP. А ещё у него самый короткий тайм ту маркет по моему опыту. На тот же IPT-server с двумя рефакторингами у меня на круг ушло часов 6 наверное.
Websockets - первое, что пришло в голову, что удобно связало код на LUA и Питоне в разных контейнерах (потенциально на разных хостах).
Без докера конечно тоже будет работать - если заводить руками, то нужен powerdns и ipt-server.
vviz
29.05.2022 20:51Прошу прощение за вклинивание :)
Насчет роутинга по символьному имени. Допустим, уже есть VDS/VPN с прокси. Подсовываем браузеру PAK файл, в котором описываем правила сравнения символьных имен. Совпадают - в прокси, нет - директ.
AlexKMK Автор
29.05.2022 21:17Да, это было первое решение. Там конечно есть нюансы но можно сделать ещё эффективнее. Обычно синие сайты выдают 403 и похожие ошибки.
Можно отправлять на апстрим в случае ошибок на основном.
Но, когда нужно задеплоить такое решение на зоопарк компов и телефонов в разных локациях - волосы встают дыбом. У меня дома в инфраструктуре только около 30 различных контейнеров, виртуалок и тд. Хочется чтоб оно было централизованно.
TheChief5055
30.05.2022 10:46Год назад где-то мне бы очень помогло что-то, что роутит запросы не по айпи, а по символьному имени.
Связка dnsmasq + ipset + iptables используется уже с незапамятных времён.
TimsTims
29.05.2022 20:40+1Парсинг DNS - действительно первое что приходит на ум.
Если у вас действительно задача только одна - заходить на заблокированные РКН сайты, то за этим списком нужно регулярно следить, что не делает ваше решение универсальным. Более того, не все сайты (например возьмём Facebook) имеют обязательно в своем название это слово. Есть много всяких cdn сервисов , и целая куча других, в которых нет заветных букв. Рано или поздно маска поиска будет настолько большой, что под раздачу попадут и российские сайты, которые вам нужно открывать с домашнего ip.
Я уж молчу, что есть ещё куча игровых сервисов, до которых желателен минимальный пинг, без впн.
Как правильно сказали в первом посте, идеальное решение - использовать bgp маршруты. Ребята с antifilter.download (ещё есть вторые antifilter.network ) сделали отличный сервис, даже писали здесь на Хабре как настроиться. Идеально работают маршрутизаторы микротик. Один раз настроил, и забыл. Если завтра заблокируют YouTube - я даже не замечу.
AlexKMK Автор
29.05.2022 21:19Проблема с блокировкой етуба и правда решается так. Но так пока что не решается проблема когда етуб и ещё пара сотен сайтов вас заблокировали ????
Айпишки и подсетки mrvpn тоже умеет ????
По поводу cdn - я изучал и там вот что : обычно все начинается с какого нибудь 123.fbcdn.net который через кучу cname резолвится в акамай. Для этого цепочки cname и анализируются.
NeoCode
29.05.2022 21:00+6Заведите несколько браузеров. Один с VPN, другой без VPN... Это также неплохой способ разделить сферы интересов, чтобы всякие веб-трекеры не слишком много про вас знали.
mayorovp
29.05.2022 21:18+1Не пробовали на стороне DNS-сервера возвращать не реальный адрес OuterNet-хоста, а виртуальный? В таком случае достаточно будет всего одного сервера.
Кстати, почему вы не используете аналог ipset в текущем решении?
AlexKMK Автор
29.05.2022 21:48По поводу виртуального не совсем понял. Поясните пожалуйста ????
Ipset - судя по всему то же самое что map в nftables. Должно быть быстрее чем просто цепочка с -j RETURN. Нужно подумать ????
mayorovp
29.05.2022 22:30Ну вот вы получили DNS-запрос для домена example.com и определили что надо его направить в OuterNet. Заменяете в ответе реальный адрес (1.2.3.4) на какой-нибудь 10.5.6.7 — в результате чего пакеты начинают идти в туннель. А на той стороне туннеля стоит правило dstnat, которое меняет 10.5.6.7 обратно на 1.2.3.4.
IIIEB4YK
31.05.2022 00:43Видимо имеется ввиду принцип, как в АнтиЗапрет: https://bitbucket.org/anticensority/antizapret-vpn-container (см. раздел Особенности VPN в описании).
pred8or
29.05.2022 21:44+2А вот как бороться с вот такими случаями выдающегося бреда?
Из дома:
nslookup www.themoviedb.org
Non-authoritative answer:
Name: www.themoviedb.org
Addresses: ::1
127.0.0.1Из Европы:
$ nslookup www.themoviedb.org
Server: 127.0.0.53
Address: 127.0.0.53#53Non-authoritative answer:
Name: www.themoviedb.org
Address: 13.32.99.70
Name: www.themoviedb.org
Address: 13.32.99.99
Name: www.themoviedb.org
Address: 13.32.99.105
Name: www.themoviedb.org
Address: 13.32.99.27Не, понятно, на одном компьютере можно решить в etc/hosts. А вот как системно, для всей домашней сети? Правда, это пока единственный сайт, на котором я на такое наткнулся
AlexKMK Автор
29.05.2022 21:46+2Точно так же - vpn + dns proxy который выходит в Европу. Ещё DoH может помочь.
AlexKMK Автор
29.05.2022 21:51У меня дома настройка - всё, что не .ru - идёт в Европу. + Днс тоже резолвится через Европу, такой проблемы в итоге не стоит. Хотя да - geo-dns работать нормально не будет увы.
Если у powerdns есть прехуки (сейчас я стою в постхуке) то можно .ru домены завести на русский днс сервер. Тогда геоднс (route53) будет норм работать.
fshp
29.05.2022 23:11+1DoH поможет только при использовании нонейм серверов. Половину запросов на популярные dns типа гугла и клауда по ip перехватываются. И DoT просто отвратительно начинает работать, т.к. сертификат не проходит валидацию. DoH тоже нужно пускать через туннель.
edo1h
30.05.2022 01:31+2Большой набор рул в nft не загрузить потому, что nft работает через RT_NETLINK так, что туда много не влезает.
а зачем большой?
у меня берётся список сетей (примерно 18к строк) и загружается в два set'а (один для ipv4, второй для ipv6).
загрузка черезnft -fзанимает 0.2 с.AlexKMK Автор
30.05.2022 10:48У меня меп который у них в примере https://github.com/pvxe/nftables-geoip для РФ в упор не хотел грузиться - говорил, что DATA TOO BIG
edo1h
30.05.2022 13:26+1странно.
не нашёл как там сделать только по выбранным странам, попробовал общий мап — загрузился (правда, грузился почти 8 секунд).
ядро 5.10у меня set, а не map, плюс только РФ — грузится, как писал выше, на полтора порядка быстрее
Darth_Malok
30.05.2022 05:14+1Вопрос, наверное, очень глупый, но его задам.
А почему не определять доступность сайта попыткой к нему подключиться? Подключаемся без vpn, получаем отказ, подключаемся по vpn и запоминаем, что по этому адресу нужно ходить через vpn. Если подключаемся по vpn, получаем отказ, подключаемся без vpn и запоминаем, что на этот айпишник нужно ходить без vpn. Если не вышло ни так ни так, сообщаем об этом пользователю (пишем в лог), и попытки подключения прекращаем.
Да, первое подключение будет дольше, чем обычно, но не всегда. Но так можно обойтись без всякой геолокации, ручных списков и т.д.
Или я чего-то не понимаю?
upd: Всё это, конечно, при условии, что цель — зайти на сайт, а не скрыть своё местоположение, дополнительно себя защитить и т.д.AlexKMK Автор
30.05.2022 06:24+1Это можно делать когда через SQUID подключаешься и именно так я сделал в первую очередь. Хотя, там списки кстати тоже нужны. hashicorp и клаудфронт возвращают 403. Но есть сайты, которые просто показывают текст без http ошибки - их только руками.
Почему я от SQUID отказался - там выше написано.
Но, если и без сквида делать, то тогда не получится вообще. Потому, что SNI в TLS v1.3 - зашифрован, и по пути банально никто не знает на какой сайт происходит подключение. Помимо этого, нужно вклиниться в TCP сессию, чтоб клиент продолжил работать после переподключения - это не так-то просто. Объем кода для перехвата HTTP сессии в режиме MITM - он гораздо выше чем то, как сделано. А если мы хотим через SFLOW перехватывать, то там еще на порядок больше работы.
Можно прикрутить кстати какой-то плагин для браузера или расширить прокси-автосвитчер. Но, всё это началось с того, что у меня на одном из компов не работал
terraform init:) а тут плагин для браузера не пойдет.
playermet
30.05.2022 06:47+4А почему не определять доступность сайта попыткой к нему подключиться?
Как минимум потому, что многие сайты отдают результат, иногда даже с успешным кодом. Просто на экране - "извинити, мы не можем вам предоставлять услуги, вот вам ссылка с подробностями".
Gudd-Head
30.05.2022 07:49+1Различные (удачные и нет попытки).
Может, лучше так:
Различные (удачные и нет) попытки.
?
cjmaxik
30.05.2022 09:09+1Для сайтов я пользуюсь расширением "Обход блокировок Рунета" в режиме "Только свои сайты и свои прокси". Соответственно, прокси на удаленном сервере (хотя можно и купить чисто прокси)
Для конкретных приложений - Windscribe VPN с включенным режимом Split Tunneling (Inclusive)
На телефоне - AdGuard + Shadowsocks в режиме прокси (включается при необходимости через flow в Automate)
ekini
30.05.2022 10:00Есть довольно простое решение, которое работает по доменам - https://en.wikipedia.org/wiki/Proxy_auto-config
Файл хостится на домашнем сервере/роутере/удаленном сервере/или даже локально на компьютере.
Нужные домены роутит через свой прокси, остальные - напрямую. Прокси может работать в докер контейнере с wireguard-only egress.
AlexKMK Автор
30.05.2022 10:49PAC кроме браузеров не поддерживает приблизительно никто. тот же terraform - не поддерживает )
blind_oracle
30.05.2022 11:20+1Можно использовать socksify, но это конечно костыль тот ещё...
AlexKMK Автор
30.05.2022 20:38терраформ умеет получать прокси через переменные окружения. Но, ведь хочется без всего этого :)
mayorovp
30.05.2022 11:06-1Против санкций ещё пойдёт (надеюсь), но при попытке использовать его для обхода блокировок у меня браузер начинал лагать из-за объёма этого файла.
emusic
30.05.2022 11:01-2возникла потребность более умного VPN, который русские сайты отправит по одному маршруту, а не-русские - по другому
Простейшее решение - банальный HTTP/HTTPS Proxy, который можно задать в браузере (глобально или в отдельном профиле). Бесплатных - море, но очень нестабильны. Казалось бы, у каждого VPN-провайдера должны быть такие серверы с авторизацией, но увы.
mayorovp
30.05.2022 11:07Банальный прокси не сможет увидеть имя сайта в HTTPS-соединениях, а потому бесполезен для этой задачи.
muxa_ru
30.05.2022 13:49-1Для этого есть автоматическая настройка прокси, которой управляет браузер - https://en.wikipedia.org/wiki/Proxy_auto-config .
mayorovp
30.05.2022 13:56-1PAC — это, конечно, решение, но оно несколько отличается от предложенного выше "банального HTTP/HTTPS Proxy".
muxa_ru
30.05.2022 14:34-2несколько - да, но не принципиально.
mayorovp
30.05.2022 14:49+1Отличие принципиальное. Прокси — это прокси, а PAC — это механизм для выбора прокси. Они никак не являются взаимозаменяемыми.
muxa_ru
30.05.2022 21:53-1Отличие принципиальное. Прокси — это прокси, а PAC — это механизм для выбора прокси. Они никак не являются взаимозаменяемыми.
PAC не заменяет прокси - он дополнительный инструмент решающий озвученную Вами проблему "Банальный прокси не сможет увидеть имя сайта в HTTPS-соединениях, а потому бесполезен для этой задачи"
Можно на уровне PAC прописать прямой доступ для доменов в зоне RU + крупные российсикие сервисы, а остальные отправлять на прокси. И никакой https этому не мешает.
Если Вы внимательно перечитаете эту ветку, то увидите, что речь изначально была именно об этом и ни о чём более.
mayorovp
31.05.2022 00:08-1А давайте вы внимательно перечитаете ветку?
muxa_ru
31.05.2022 00:31-1Перечитываю.
Вы пишете: " Банальный прокси не сможет увидеть имя сайта в HTTPS-соединениях, а потому бесполезен для этой задачи. "
Я пишу: " Для этого есть автоматическая настройка прокси, которой управляет браузер - https://en.wikipedia.org/wiki/Proxy_auto-config . "
Дальше Вы начинаете спорить с выдуманной Вами же идеей о замене прокис на PAC.mayorovp
31.05.2022 09:40А вы читайте комментарием раньше, и в контексте поста.
Автор пишет: "мне нужен механизм переключения между InnerNet и OuterNet".
emusic пишет: "для этого можно использовать … прокси".
Я ему пишу: "прокси сам по себе не может быть решением проблемы автора, нужно что-то ещё"
И тут вы начинаете говорить про PAC. Ну да, PAC является одним из вариантов, который бы мог помочь автору. Но как, блин, это отменяет тот факт, что прокси сам по себе не может быть решением проблемы автора?
nidalee
31.05.2022 09:52-1HTTP прокси таки может, я squid на VPS в РФ скармливаю список заблокированных доменов, и он ходит на них через еще один squid, но уже в другой стране (acl whitelist dstdomain + never_direct allow all).
Если первый squid поднять локально, то до не заблокированных сайтов получится вообще прозрачно. А список доменов можно подтягивать простым wget-ом как раз с забугорного squid-а.
Получается быстро, но уже не работает с некоторыми сайтами. Дальше, я полагаю, ситуация будет только ухудшаться, по мере роста усердия РКН.
А вот HTTPS прокси я не осилил. После дня гугления так и не понял, существуют ли они вообще, или это только MITM-ы.
mayorovp
31.05.2022 10:34Ну разумеется, чистый HTTP может. Проблема только в том, что уже 10 лет как весь интернет переходит на HTTPS.
А вот при проксировании HTTPS используются не обычные методы HTTP, а метод CONNECT. Поэтому единственный способ "заглянуть" внутрь и что-то сделать — это терминировать TLS на стороне прокси. Да, прокси становится при этом MITM.
nidalee
31.05.2022 11:41Весь HTTPS-интернет вполне себе работает через HTTP прокси. Кроме, собственно, CDN Instagram. На данный момент.
У меня больше года все сайты ходили через HTTP прокси, в черном списке были только несколько сайтов, которыммордаIP VPS не нравился. Все работало нормально.
Я так понимаю, почти все прокси серверы уже умеют CONNECT. Кроме, например, nginx. Для него нужен патч.
3proxy и squid точно умеют гонять HTTPS работая при этом через HTTP.Выдержка из CURL, как это выглядит без вмешательства РКН:А вот пересадить их (чтобы РКН не лез ручонками смотреть, куда прешь) на HTTPS уже да — проблема. Благо пока он почему-то ищет только cdninstagram.com, все остальное его не смущает, включая трекеры и Linux ISO's.curl -v -x http://*** https://scontent-hou1-1.cdninstagram.com
* Trying ***...
* TCP_NODELAY set
* Connected to *** port *** (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to scontent-hou1-1.cdninstagram.com:443
* Proxy auth using Basic with user '***'
> CONNECT scontent-hou1-1.cdninstagram.com:443 HTTP/1.1
> Host: scontent-hou1-1.cdninstagram.com:443
> Proxy-Authorization: Basic ***
> User-Agent: curl/7.68.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CONNECT phase completed!
* CONNECT phase completed!
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_CHACHA20_POLY1305_SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=California; L=Menlo Park; O=Facebook, Inc.; CN=*.instagram.com
* start date: Mar 1 00:00:00 2022 GMT
* expire date: May 30 23:59:59 2022 GMT
* subjectAltName: host "scontent-hou1-1.cdninstagram.com" matched cert's "*.cdninstagram.com"
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55e4f93f7d80)
> GET / HTTP/2
> Host: scontent-hou1-1.cdninstagram.com
> user-agent: curl/7.68.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 204
< cache-control: max-age=86400, must-revalidate
< cross-origin-resource-policy: cross-origin
< content-type: text/plain
< server: proxygen-bolt
< x-fb-trip-id: 1679558926
< date: Mon, 23 May 2022 11:59:27 GMT
< alt-svc: h3=":443"; ma=86400,h3-29=":443"; ma=86400
<
* Connection #0 to host *** left intact
Выходит смешно: instagram через прокси загружается, а вот фото и видео уже нет. Чудеса.
mayorovp
31.05.2022 16:12-1Я так понимаю, почти все прокси серверы уже умеют CONNECT.
Вот только уметь CONNECT и уметь заглянуть внутрь CONNECT — две большие разницы. Для второго требуется провести MITM-атаку.
emusic
30.05.2022 20:12-1Для этой задачи (с отдельным профилем браузера) прокси-серверу нет необходимости что-либо "видеть". А задачи разделять трафик между множеством путей не ставилось.
mayorovp
30.05.2022 20:57-1В смысле — не ставилось? А это тогда что:
возникла потребность более умного VPN, который русские сайты отправит по одному маршруту, а не-русские — по другому
emusic
30.05.2022 21:30-1Вот я и описал простейшее решение - браузер с двумя профилями (в двух экземплярах), плюс мозг, который для русских сайтов использует один экземпляр, а для остальных - другой.
Но, конечно, если очень хочется в гамаке на лыжах, то можно возиться и автоматизированными решениями. Но они все равно не будут 100% автоматическими, поскольку конфигурацию придется регулярно допиливать.
edo1h
31.05.2022 00:56+1Вот я и описал простейшее решение — браузер с двумя профилями (в двух экземплярах), плюс мозг, который для русских сайтов использует один экземпляр, а для остальных — другой.
это работает пока вам нужен только веб.
emusic
31.05.2022 14:39Ну так "сайт" - это и есть "только веб". Все остальное - это "сервер", "узел" и т.п.
vikarti
01.06.2022 07:11Хорошо. Я же правильно понимаю тогда что решение с отдельным браузером поможет ну например при блокировке dl.google.com (что было уже ) и обновлении Android SDK из Android Studio? Как именно?
Обновляется все вполне себе по https, с сайтов.
blind_oracle
30.05.2022 11:21Как по мне гораздо проще PBR на базе GeoIP плюс отдельный белый список для выдающихся кто сидит на зарубежных адресах и пускает только с русских. Я не думаю что их очень много.
AlexKMK Автор
30.05.2022 12:13так это оно и есть :) список формируется автоматически - вот и вся разница )
edo1h
31.05.2022 00:58кто сидит на зарубежных адресах и пускает только с русских
а пример можно? я пока с таким не встречался
shredder2003
30.05.2022 12:13+2Когда столкнулся с таким, решил, что список нужных росс. ресурсов, недоступных извне, конечен, а список недоступных внешних ресурсов, потенциально бесконечен.
Хотел найти список таких ресурсов, но почему-то не нашёл и создал свой https://github.com/shredder2003/russianNoVPNservices/blob/main/hosts.csv
А дальше ещё и программку, которая по списку ресурсов проходится, и в роутер забивает маршруты по этим ресурсам. Два месяца использую - проблем нет.
edo1h
31.05.2022 00:58ну как минимум отзывчивость сайтов страдает.
shredder2003
31.05.2022 17:13да, мне показалось, когда всё пустил через впн, что mail.ru как-то дольше стал открываться, потому и добавил его в список исключений. С остальным разницы не почувствовал.
DaemonGloom
31.05.2022 13:46Проблема такого подхода — всевозможные CDN, добавлять их вручную на каждое изменение — процесс печальный.
А на тему цепочек — есть хорошая картинка, которая показывает путь пакетов в мозгах микротиков:
https://www.mikrotik-trainings.com/trainings_files/docs/MikroTik_PacketFlow_Routing24.jpgshredder2003
31.05.2022 17:20CDN - речь про то, что на одно доменное имя могут в случайном порядке выдаваться разные IP? Если про это, то да, насколько помню, mos.ru такой. И да, вручную добавлять-обновлять неприятно, потому и написал программу, которая сначала делает 20 резолвов имени, затем на все полученные IP маршруты создаёт. Таким образом, если что-то перестало работать, достаточно запустить программу ещё раз, она дорезолвит недостающие IP и пропишет их в маршруты роутера (Keenetic).
DaemonGloom
31.05.2022 17:43Там достаточно часто ещё и имена новые появляются. И их автоматически узнать уже сложнее. Пример — тот же инстаграм, у которого есть туча адресов в домене fbcdn. И если основной сайт открывается по одному и тому же адресу, то фотографии хранятся по куче поддоменов.
shredder2003
31.05.2022 18:13Для инсты-фейсбука в гитхабе кто-то ведёт список подсетей, а для России я с такой жестью ещё не сталкивался.
Да и сомневаюсь что для госуслужных сайтов настолько сложная структура будет - типа автоматической генерации поддоменов.
ValdikSS
30.05.2022 12:27+6Задача решена эффективно и конкретно под Россию на голову выше предлагаемых альтернатив: https://bitbucket.org/anticensority/antizapret-vpn-container/src/
Не понимаю, почему её никто не крадёт.Особенности VPN
Нестандартный способ маршрутизации
В отличие от обычных VPN, осуществляющих перенаправление отдельных IP-адресов или диапазонов средствами маршрутизации ОС, VPN АнтиЗапрета использует маршрутизацию на основе доменных имен, с помощью специального DNS-сервера, созданного для этой цели.
На VPN-сервере запущен специальный DNS-резолвер, устанавливающий отображение (соответствие, маппинг) настоящего IP-адреса домена в свободный IP-адрес большой внутренней подсети, и отдающий запрашиваемому клиенту адрес из внутренней подсети.
У такого подхода есть множество преимуществ:
Клиенту устанавливается только один или несколько маршрутов, вместо десятков тысяч маршрутов;
Маршрутизируются только заблокированные домены, а не все сайты на заблокированном IP-адресе;
Возможность обновления списка заблокированных сайтов без переподключения клиента;
Корректная работа с доменами, постоянно меняющими IP-адреса, и с CDN-сервисами;
Корректная работа с провайдерами, блокирующими все поддомены заблокированного домена (блокировка всей DNS-зоны). Пример такого провайдера — Yota.
Но есть и минусы:
Необходимо использовать только DNS-сервер внутри VPN. С другими DNS-серверами работать не будет.
Работает только для заблокированных доменов и программ, использующих доменные имена. Для заблокированных IP-адресов необходимо использовать обычную маршрутизацию.
Схематичное представление:
???? — Клиент ???? — VPN и DNS-сервер ???? — Интернет ???? → rutracker.org? → ???? ???? → rutracker.org? → ???? ???? ← 195.82.146.214 ← ???? 10.224.0.1 → 195.82.146.214 ???? ← 10.224.0.1 ← ????Обычная способ маршрутизации также применяется, но только для больших диапазонов заблокированных адресов (всего несколько маршрутов).
edo1h
30.05.2022 13:31+2Маршрутизируются только заблокированные домены, а не все сайты на заблокированном IP-адресе;
сегодня всё чаще закрывают не из РФ, а от РФ, так что этого недостаточно. поддерживать и постоянно актуализировать список всех заблокированных с обеих сторон ресурсов — то ещё удовольствие.
я давно перевёл доступ ко всем иностранным хостам через VPN, на задержках до европейских/американских сайтов почти не сказалось (так и так трафик через европу идёт).
ValdikSS
30.05.2022 14:07сегодня всё чаще закрывают не из РФ, а от
РФ, так что этого недостаточно. поддерживать и постоянно
актуализировать список всех заблокированных с обеих сторон ресурсов — то
ещё удовольствие.Для этого существует разделение на distro-список, который поставляет автор контейнера, и custom-список, который пользователь может редактировать самостоятельно.
К тому же, это решение можно использовать и на стороне сервера, машрутизируя разные домены в разные VPN-каналы на сервере, а не на клиенте (у клиента один конфиг к одному серверу, а сервер сам решает, через какую страну маршрутизировать).
edo1h
30.05.2022 18:51который пользователь может редактировать самостоятельно.
ну я про это и говорю «постоянно актуализировать»
К тому же, это решение можно использовать и на стороне сервера, машрутизируя разные домены в разные VPN-каналы на сервере, а не на клиенте
ну опять же нужен актуальный список доменов.
а тут один раз залил список ip-сетей и спишь спокойно (на самом деле обновление тоже настроил, но сначала несколько недель сидел без него, всё работало ровно так же; ip-сети не так уж часто выделяются/мигрируют)
muxa_ru
30.05.2022 13:45Зачем людям ранее был нужен VPN (кроме мошенников конечно)? Чтоб ходить на Linkedin и обходить всякие разные запреты РКН.
А вот это какой из двух вариантов? :)
How To Get US Netflix In Australia Using Opera’s Free VPN
Chris Jager
Published 6 years ago: April 22, 2016 at 4:30 pm
https://www.lifehacker.com.au/2016/04/how-to-get-us-netflix-in-australia-using-operas-free-vpn/
Tarakanator
30.05.2022 14:36я с микротом забавно облажался.
Есть локальный IP, маркирую с него весь трафик мол иди через VPN.
Реальность:
На роутер прилетает пакет
local_ip->8.8.8.8:53
Роутер, о я с этого ip маркирую всё to_vpn получаем пакет:
local_ip->8.8.8.8:53 routing_mark: to_vpn
Роутер, что у нас там дальше. Дальше у нас DST_NAT. Это же 53 порт, незащищённый DNS. Срочно перехватываем трафик.
local_ip->local_router_ip:53 routing_mark: to_vpn
Роутер, а дальше у нас решение о маршрутизации. Смотрим таблицу to_vpn.
local_net/24 distance 49 gateway LAN
0.0.0.0/0 distance 50 gateway VPN
local_router_ip входит в local_net/24
пакет улетает обратно в локалку
P.S. Я Так и не понял как красиво описать данную ситуацию. Сейчас убиваю роутинг марки на DNS сервера, но смотрится как-то костыльно.
kterik
30.05.2022 19:00Очевидно, в правиле dst-nat следует ограничить интерфейс и/или маркировку маршрута, в зависимости от желаемого результата.
Tarakanator
31.05.2022 08:52Так интерфейс по в любом случае LAN.
И перехватываться должны все DNS запросы, независимо от маркировки маршрута.kterik
31.05.2022 09:02Если есть необходимость убрать NAT из DNS-трафика через VPN, то правило dst-nat позволяет выбрать условие !routing-mark. Это позволит исключить часть пакетов из dst-nat.
Если есть необходимость убрать DNS-трафик из VPN, то правило mangle prerouting позволяет выбрать условие dst-port. Это позволит исключить часть пакетов из таблицы to_vpn.
Tarakanator
31.05.2022 09:10Есть желание убрать весь нешифрованный DNS наружу.
то правило mangle prerouting позволяет выбрать условие dst-port
Не получится, чтобы выбрать !dst-port нужно выбрать протокол, а мне нужно для всех протоколов.
kterik
31.05.2022 09:41Не получится, чтобы выбрать !dst-port нужно выбрать протокол, а мне нужно для всех протоколов.
В этом случае можно продублировать правило mangle цепочки prerouting, разместить его первым и выбрать в нём действие accept, чтобы пакет не проходил через другие правила mangle той же цепочки. В этом новом правиле следует указать дополнительное условие: протокол/порт UDP/53. Тогда пакет не получит маркировку маршрута.
При необходимости можно создать аналогично правило для запросов TCP/53.
Tarakanator
31.05.2022 11:41Уже как-то некрасиво получается.
Я вообще понять не могу, почему он routing decision делает в forward, а не в input.kterik
31.05.2022 11:55Если в результате dst-nat цепочки prerouting пакет перенаправляется на интерфейс микротика, то затем должна быть цепочка input. Если вместо этого пакет идёт по цепочке forward, значит, что-то здесь не так и надо искать причину.
edo1h
30.05.2022 19:05Роутер, что у нас там дальше. Дальше у нас DST_NAT. Это же 53 порт, незащищённый DNS. Срочно перехватываем трафик.
но зачем? чтобы
dig +traceперестал работать?
да и вообще, я ожидаю, чтоdig ya.ru @8.8.8.8выдаст мне ответ именно от 8.8.8.8.
а тем клиентам, которым надо использовать мой dns, я его через dhcp выдам.Я Так и не понял как красиво описать данную ситуацию. Сейчас убиваю роутинг марки на DNS сервера, но смотрится как-то костыльно.
не смотрел, что сделали в микротике, но в обычном линухе:
# ip ru 0: from all lookup local 102: from all fwmark 0x66 lookup 102 104: from all fwmark 0x68 lookup 104 199: from all fwmark 0xc7 lookup 199 220: from all lookup 220 32766: from all lookup main 32767: from all lookup defaultв таблице с максимальным приоритетом прописаны все локальные адреса.
Tarakanator
31.05.2022 08:55но зачем?
а тем клиентам, которым надо использовать мой dns, я его через dhcp выдам.
Чтобы особо умные не использовали нешифрованный DNS.
не смотрел, что сделали в микротике, но в обычном линухе:
Поправьте если я ошибаюсь, но ведь там для случая когда надо перенаправить трафик НА адреса в ВПН.
Мне же надо пперенаправить трафик С адреса в ВПН
DaemonGloom
31.05.2022 13:54Покажите лучше эти правила экспортом конфигурации, будет понятнее.
Второй вопрос — а зачем вам вообще перехватывать 53 порт в DST_NAT, шлите его спокойно в тоннель по первому правилу с маркировкой.Tarakanator
31.05.2022 14:015 ;;; 2VPN
chain=prerouting action=mark-routing new-routing-mark=VPN passthrough=yes dst-address=!192.168.0.0/16 src-address-list=2VPN log=no log-prefix=""6 ;;; 2VPN exclude DNS
chain=prerouting action=mark-routing new-routing-mark=main passthrough=yes dst-address=94.140.14.14 src-address-list=2VPN log=no log-prefix=""4 ;;; unsecure DNS redirect
chain=dstnat action=redirect to-ports=53 protocol=udp src-address=192.168.0.0/16 dst-address=!192.168.0.0/16 dst-port=53 log=no log-prefix=""5 ;;; unsecure DNS redirect TCP
chain=dstnat action=redirect to-ports=53 protocol=tcp src-address=192.168.0.0/16 dst-address=!192.168.0.0/16 dst-port=53 log=no log-prefix=""Второй вопрос — а зачем вам вообще перехватывать 53 порт в DST_NAT, шлите его спокойно в тоннель по первому правилу с маркировкой.
Ну так тоннелю я не доверяю. не хочу туда нешифрованный трафик слать.
DaemonGloom
31.05.2022 14:39Я так понимаю, ваш микротик после получения пойманного пакета уже сам по безопасному протоколу стучится до выбранного вами DNS (94.140.14.14)? Если да — зачем вам правило 6 в том виде, в каком оно есть?
А на тему цепочек — есть хорошая картинка, которая показывает путь пакетов в мозгах микротиков:
https://www.mikrotik-trainings.com/trainings_files/docs/MikroTik_PacketFlow_Routing24.jpg
Ваша проблема в том, что mangle срабатывает до dst-nat. Соответственно, чтобы эти пакеты не ушли в другую таблицу — их нужно mangle правилом (перехватывающим весь 53 порт) достать в основную.Tarakanator
31.05.2022 14:49Если да — зачем вам правило 6 в том виде, в каком оно есть?
Всё именно так.
Правило 6 нужно для того чтобы вместо метки VPN, установилась метка по умолчанию main.
Именно такой вид ну просто так получилось. Если причесать то конечно там должен быть 53 порт, а дестинейшн IP фильтр.Ваша проблема в том, что mangle срабатывает до dst-nat.
Нет моя проблема в Routing decision(хотя конечно если поменять местами dst-nat и mangle, то всё заработает). Почему он решает отправить в forward, а не в input?
Кстати у меня Ros 7.2.3. На ros 6 говорят направляет в input.Соответственно, чтобы эти пакеты не ушли в другую таблицу
Я хотел бы смириться с тем, что отправляют в другую таблицу и отредактировать эту таблицу так, чтобы она работала корректно.
DaemonGloom
31.05.2022 15:59Почему он решает отправить в forward, а не в input?
Может быть интересно попробовать поменять в правилах для DNS action на dst-nat вместо redirect и указать целевой ip адрес роутера из нужной подсети. Просто redirect подставляет "какой-то" из адресов роутера и не обязательно нужный.
Tarakanator
31.05.2022 16:03Это я проверял, IP подставляется нужный.
остановил гугленье на том, что в ROS6 это работает, а в 7-й версии нет.
отправил запрос баг ли это.kterik
31.05.2022 18:52Возможно, ROS7 более vrf-aware, чем ROS6, и поэтому DNS-запрос, направленный в таблицу VPN, не найдя в ней указанный адрес назначения, перенаправляется по умолчательному маршруту наружу (соответственно, в цепочку forward). Хотя этот адрес принадлежит самому микротику в таблице main.
Если так, то это даже радует. VRF на ROS6 дюже дырявый.
Krey
31.05.2022 05:11+2nftables это тоже netfilter, непонятно почему вы им отказываете в родстве. И все это под капотом работает через bpf, который можно конфигурировать напрямую. И да, есть списки и это не map.
PS У меня схожим образом давно работает домашний роутер, только список маленький и статический и рефрешится по крону.
IIIEB4YK
31.05.2022 05:44+1У меня схожим образом давно работает домашний роутер, только список маленький и статический и рефрешится по крону
Звучит как начало поста ????
AlexKMK Автор
31.05.2022 07:36ммммм. я не соглашусь. потому, что для NFT есть iptables-legacy. Таки это другая организация в ядре.
NFT не мог решить одну из этих двух задач (в принципе не мог) :
у нас есть два айпи и два интерфейса (без бонда) в одной подсети с одинаковой метрикой.
мы по какому-то принципу, натим пакеты либо в один либо в другой.
И там было по-моему так : исходящий пакет не всегда (что-то одно, что точно - не помню) :
выходил с нужного интерфейса.
выходил с нужным маком.
выходил с нужным ипом.
т.е. связка : исходящий интерфейс - мак - айпи не всегда в такой ситуации была корректной. Я перепробовал всё - от ebt и PBR до ipt. и только на NFT я решил с пол пинка.
Krey
31.05.2022 07:59Организация в ядре одна и таже что у ipt, что у nft и, внезапно, у tcpdump. Это BPF. По крайней мере в актуальных линуксах. Все эти фильтры развивались командой netfilter и, со временем, сверху остались только бэкэнды к общей подсистеме ядра, для сохранения совместимости и User experience. Причём прошу не путать новый bpfilter с собственно подсистемой BPF. Это тоже бэкэнд. Вы его можете ставить или не ставить, а подсистема есть всегда.
Что касается вашего примера, то пакеты помечаются в принципе одинаково что в nft, что в ipt, видимо какая то минорная ошибка у вас была.
У меня наоборот возникли проблемы с nft, пока я не полез в код и не сравнил приоритеты хуков с их вики. Отписал, в вики поправили.
В nft есть трейсинг, удобно отлаживать правила.
fshp
Маркировка в mangle слишком дорого. В том же микротике fasttrack не будет работать. Но за альтернативу спасибо.
Для себя выбрал wireguard + BGP https://antifilter.download/
Там конечно тоже некоторые маршруты фильтровать нужно. Но лично у меня в фильтре всего 5 подсетей сейчас реджектится.
Огромный плюс в том, что переключив дефолтный маршрут, можно одной кнопкой весь трафик в туннель пустить временно.
belyvoron
К сожалению, кроме напасти с РКН, появилась другая напасть, что владельцы зарубежных сервисов стали не жаловать российские IP адреса. Поэтому разделение по спискам РКН не очень помогает.
fshp
Как раз для этого меняю маршрут дефолтный если разово нужно, или потом дописываю статический. Пока столкнулся с двумя проблемами только за год наверное. Пикабу не пускает из vpn, пришлось фильтры сделать, а Microsoft наоборот не даёт скачать дистрибутивы из России. Я понимаю, что вы на другие сайты ходите, но списки решают пожалуй 99% проблем, остальное под себя конечно допиливать.
TheChief5055
Интересно, в том, что дней 5 тому обратно перестали работать все сервисы Syncthing, кто виноват? Отвалилось всё — апдейты, relays, discovery servers. Хвала всем богам, у них доступен для самостоятельной установки приватный discovery server, который в т.ч. имеется в виде docker. Поднялось, полетело, но осадочек остался.
vikarti
На выбор:
TheChief5055
Даже не знаю. Всё такое вкусное…
IIIEB4YK
РКН, см. https://habr.com/ru/news/t/667096
PrinceKorwin
У вас с wireguard не замечали, что скорость плавающая? 30 сек или около того стабильно, и 30 сек пауза?
Все перепроверил. Ощущение, что шейпится трафик провайдером. Пробовал трёх разных включая сотовую связь. Наибольшие задержки у сотовой связи.
Но стоило выехать в Беларусь и все проблемы пропали...
fshp
Россия, Ростелеком. Скорость упирается в роутер. CPU на 300 мегабитах на 100% нагружен. Скорость до vps вне тоннеля гигабит.
Просадок не замечал. Максимум что пришлось, так это с mss подшаманить.
Пустите iperf напрямую и через тоннель для сравнения.
PrinceKorwin
Спасибо за подсказку, попробую.
Не написал сразу. Выходная точка - DO, Германия.
ubuntuandrew
У меня, кстати, есть аналогичная проблема - впечатление, что канал просто "рвется" через 30-60 сек. Тоже DO, Франкфурт, проблемы на Дом РУ в основном
fshp
DO Лондон. Ни единого разрыва.
Правда есть баг в самом микротике. Ровно через 7 дней WG перестает работать, лечится только перезагрузкой. Может руки кривые.
ConstSe
У меня Дом.Ру и сервер в Linode в Германии. Wireguard тоже проседает временами по скорости. Не отслеживал ещё статистику, но бывает 30 мегабит (я в деревне, такой канал), а бывает 1-2.
AlexKMK Автор
У меня стоит в ноутбуке L850-GL модем. Через него погано всё работает (оператор Мегафон), очень часто плююсь и всё пытаюсь завести Сьерру. 30 секунд работает - потом просто траф пропадает и всё.
Когда подключаешь ноут через телефон (тоже оператор Мегафон) - всё работает шикарно.
Дома Ростелек. Ничего "такого" не заметил. Хотя, спидтестом тоннель не замерял.
Однако, я WG использую очень давно : я работаю на терминалах (RDP/NoMachine) - ибо так на ноуте батарейка не садится и под каждую задачу своя виртуалка где-нибудь :) Каких-то лагов в гуе не замечал. Всё комфортно, как будто локально.
А MSS шаманить очень нужно. Либо MTU резать до 1280. Но лучше MSS. Там одна строчка для IPT
solver
Это в кинетике он не будет работать, т.к. там "фастрак" (или как его назвали в кинетике "сетевой ускоритель") можно либо включить на всё устройство, либо выключить.
А вот в микротике с этим всё на много лучше, фасттрак это не абстрактная фича, а обычное правило в фаерволе, со всеми вытекающими из этого возможностями по его настройке. Так что можно в нём указать чтобы фасттрак работал для всего, кроме ресурсов завёрнутых по правилу. И без фасттрака будут жить только небольшое число нужных ресурсов. Но для таких ресурсов это обычно не так критично.
fshp
Даже без него интернет будет работать у среднестатистического пользователя без каких-то изменений. Во первых в домашних микротиках редко развесистая пачка правил, что бы хоть как-то замедляло трафик. Во вторых, большую часть времени роутер простаивает. Однако на на душе все рано не спокойно.
Abyss777
У меня так не работает ozon.
Даже если я добавлю его в исключения (идти напрямую) там идёт сначала редирект на CloudFlare, который естественно меня определяет как заграницу.
весь CloudFlare делать через РФ тоже неправильно, куча всего остального отвалится...
Так решения и не придумал.
antifilter конечно удобен, но из-за агрегации до /24 приходится делать исключения
AlexKMK Автор
В текущем конфиге - я озон нормально завел.