Комментарии 130
Маркировка в mangle слишком дорого. В том же микротике fasttrack не будет работать. Но за альтернативу спасибо.
Для себя выбрал wireguard + BGP https://antifilter.download/
Там конечно тоже некоторые маршруты фильтровать нужно. Но лично у меня в фильтре всего 5 подсетей сейчас реджектится.
Огромный плюс в том, что переключив дефолтный маршрут, можно одной кнопкой весь трафик в туннель пустить временно.
К сожалению, кроме напасти с РКН, появилась другая напасть, что владельцы зарубежных сервисов стали не жаловать российские IP адреса. Поэтому разделение по спискам РКН не очень помогает.
Как раз для этого меняю маршрут дефолтный если разово нужно, или потом дописываю статический. Пока столкнулся с двумя проблемами только за год наверное. Пикабу не пускает из vpn, пришлось фильтры сделать, а Microsoft наоборот не даёт скачать дистрибутивы из России. Я понимаю, что вы на другие сайты ходите, но списки решают пожалуй 99% проблем, остальное под себя конечно допиливать.
Интересно, в том, что дней 5 тому обратно перестали работать все сервисы Syncthing, кто виноват? Отвалилось всё — апдейты, relays, discovery servers. Хвала всем богам, у них доступен для самостоятельной установки приватный discovery server, который в т.ч. имеется в виде docker. Поднялось, полетело, но осадочек остался.
На выбор:
- Путин
- Байден
- Зеленский
- Липов (который вместо Жарова РКН возглавляет)
РКН, см. https://habr.com/ru/news/t/667096
У вас с wireguard не замечали, что скорость плавающая? 30 сек или около того стабильно, и 30 сек пауза?
Все перепроверил. Ощущение, что шейпится трафик провайдером. Пробовал трёх разных включая сотовую связь. Наибольшие задержки у сотовой связи.
Но стоило выехать в Беларусь и все проблемы пропали...
Россия, Ростелеком. Скорость упирается в роутер. CPU на 300 мегабитах на 100% нагружен. Скорость до vps вне тоннеля гигабит.
Просадок не замечал. Максимум что пришлось, так это с mss подшаманить.
Пустите iperf напрямую и через тоннель для сравнения.
Спасибо за подсказку, попробую.
Не написал сразу. Выходная точка - DO, Германия.
У меня, кстати, есть аналогичная проблема - впечатление, что канал просто "рвется" через 30-60 сек. Тоже DO, Франкфурт, проблемы на Дом РУ в основном
DO Лондон. Ни единого разрыва.
Правда есть баг в самом микротике. Ровно через 7 дней WG перестает работать, лечится только перезагрузкой. Может руки кривые.
У меня Дом.Ру и сервер в Linode в Германии. Wireguard тоже проседает временами по скорости. Не отслеживал ещё статистику, но бывает 30 мегабит (я в деревне, такой канал), а бывает 1-2.
У меня стоит в ноутбуке L850-GL модем. Через него погано всё работает (оператор Мегафон), очень часто плююсь и всё пытаюсь завести Сьерру. 30 секунд работает - потом просто траф пропадает и всё.
Когда подключаешь ноут через телефон (тоже оператор Мегафон) - всё работает шикарно.
Дома Ростелек. Ничего "такого" не заметил. Хотя, спидтестом тоннель не замерял.
Однако, я WG использую очень давно : я работаю на терминалах (RDP/NoMachine) - ибо так на ноуте батарейка не садится и под каждую задачу своя виртуалка где-нибудь :) Каких-то лагов в гуе не замечал. Всё комфортно, как будто локально.
А MSS шаманить очень нужно. Либо MTU резать до 1280. Но лучше MSS. Там одна строчка для IPT
В том же микротике fasttrack не будет работать.
Это в кинетике он не будет работать, т.к. там "фастрак" (или как его назвали в кинетике "сетевой ускоритель") можно либо включить на всё устройство, либо выключить.
А вот в микротике с этим всё на много лучше, фасттрак это не абстрактная фича, а обычное правило в фаерволе, со всеми вытекающими из этого возможностями по его настройке. Так что можно в нём указать чтобы фасттрак работал для всего, кроме ресурсов завёрнутых по правилу. И без фасттрака будут жить только небольшое число нужных ресурсов. Но для таких ресурсов это обычно не так критично.
У меня так не работает ozon.
Даже если я добавлю его в исключения (идти напрямую) там идёт сначала редирект на CloudFlare, который естественно меня определяет как заграницу.
весь CloudFlare делать через РФ тоже неправильно, куча всего остального отвалится...
Так решения и не придумал.
antifilter конечно удобен, но из-за агрегации до /24 приходится делать исключения
А есть где-нибудь список доменов/ip которые не пускают с российским ip?
Как минимум есть список присоединившихся к исполнению санкций.
Это круто, конечно! Год назад где-то мне бы очень помогло что-то, что роутит запросы не по айпи, а по символьному имени. То есть всё, в чём есть, например, слово youtube, нужно направлять в vpn, а всё, где его нет, мимо vpn. Да и сейчас это мне пригодится. Я так понимаю mrvpn либо это уже может, либо надо только совсем немного поправить код. Бурные апплодисменты!
У меня ещё есть пара вопросов, прямого отношения к делу не имеющих. Насколько я понимаю ваше решение поднимает несколько докер-контейнеров, в одном из которых сервис на питоне.
Прежде всего хочу спросить почему именно Питон. Без намерения критиковать, просто собираю причины, которыми люди руководствуются, когда выбирают язык.
Ещё интересно, почему именно веб-сокеты. Почему не обыкновенные сокеты (не знаю, как их правильно назвать )) ) или не unix domain sockets?
И, наконец, как я понимаю, докер выбран для удобства развёртывания? Впринципе ничего же не мешает всё это поднять локально без контейнеров?
Нетипичный хабр - комментаторы задают интересные вопросы ???
Да, mrvpn именно это и делает - есть вайтлист регулярок доменов. Все, что в вайтлисте - идёт без впн. Что не в вайтлисте - идёт в ВПН. Если речь идёт об отправке в ВПН одного домена и всё - нужно страны убрать из настроек и оставить только регулярку для етуба с negative match.
С питоном все просто - опыт и любовь после 20+ лет с++, ассемблера и других языков типа PHP. А ещё у него самый короткий тайм ту маркет по моему опыту. На тот же IPT-server с двумя рефакторингами у меня на круг ушло часов 6 наверное.
Websockets - первое, что пришло в голову, что удобно связало код на LUA и Питоне в разных контейнерах (потенциально на разных хостах).
Без докера конечно тоже будет работать - если заводить руками, то нужен powerdns и ipt-server.
Прошу прощение за вклинивание :)
Насчет роутинга по символьному имени. Допустим, уже есть VDS/VPN с прокси. Подсовываем браузеру PAK файл, в котором описываем правила сравнения символьных имен. Совпадают - в прокси, нет - директ.
Да, это было первое решение. Там конечно есть нюансы но можно сделать ещё эффективнее. Обычно синие сайты выдают 403 и похожие ошибки.
Можно отправлять на апстрим в случае ошибок на основном.
Но, когда нужно задеплоить такое решение на зоопарк компов и телефонов в разных локациях - волосы встают дыбом. У меня дома в инфраструктуре только около 30 различных контейнеров, виртуалок и тд. Хочется чтоб оно было централизованно.
Год назад где-то мне бы очень помогло что-то, что роутит запросы не по айпи, а по символьному имени.
Связка dnsmasq + ipset + iptables используется уже с незапамятных времён.
Парсинг DNS - действительно первое что приходит на ум.
Если у вас действительно задача только одна - заходить на заблокированные РКН сайты, то за этим списком нужно регулярно следить, что не делает ваше решение универсальным. Более того, не все сайты (например возьмём Facebook) имеют обязательно в своем название это слово. Есть много всяких cdn сервисов , и целая куча других, в которых нет заветных букв. Рано или поздно маска поиска будет настолько большой, что под раздачу попадут и российские сайты, которые вам нужно открывать с домашнего ip.
Я уж молчу, что есть ещё куча игровых сервисов, до которых желателен минимальный пинг, без впн.
Как правильно сказали в первом посте, идеальное решение - использовать bgp маршруты. Ребята с antifilter.download (ещё есть вторые antifilter.network ) сделали отличный сервис, даже писали здесь на Хабре как настроиться. Идеально работают маршрутизаторы микротик. Один раз настроил, и забыл. Если завтра заблокируют YouTube - я даже не замечу.
Проблема с блокировкой етуба и правда решается так. Но так пока что не решается проблема когда етуб и ещё пара сотен сайтов вас заблокировали ?
Айпишки и подсетки mrvpn тоже умеет ?
По поводу cdn - я изучал и там вот что : обычно все начинается с какого нибудь 123.fbcdn.net который через кучу cname резолвится в акамай. Для этого цепочки cname и анализируются.
Заведите несколько браузеров. Один с VPN, другой без VPN... Это также неплохой способ разделить сферы интересов, чтобы всякие веб-трекеры не слишком много про вас знали.
Не пробовали на стороне DNS-сервера возвращать не реальный адрес OuterNet-хоста, а виртуальный? В таком случае достаточно будет всего одного сервера.
Кстати, почему вы не используете аналог ipset в текущем решении?
По поводу виртуального не совсем понял. Поясните пожалуйста ?
Ipset - судя по всему то же самое что map в nftables. Должно быть быстрее чем просто цепочка с -j RETURN. Нужно подумать ?
Ну вот вы получили DNS-запрос для домена example.com и определили что надо его направить в OuterNet. Заменяете в ответе реальный адрес (1.2.3.4) на какой-нибудь 10.5.6.7 — в результате чего пакеты начинают идти в туннель. А на той стороне туннеля стоит правило dstnat, которое меняет 10.5.6.7 обратно на 1.2.3.4.
Видимо имеется ввиду принцип, как в АнтиЗапрет: https://bitbucket.org/anticensority/antizapret-vpn-container (см. раздел Особенности VPN в описании).
А вот как бороться с вот такими случаями выдающегося бреда?
Из дома:
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#53
Non-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. А вот как системно, для всей домашней сети? Правда, это пока единственный сайт, на котором я на такое наткнулся
Точно так же - vpn + dns proxy который выходит в Европу. Ещё DoH может помочь.
У меня дома настройка - всё, что не .ru - идёт в Европу. + Днс тоже резолвится через Европу, такой проблемы в итоге не стоит. Хотя да - geo-dns работать нормально не будет увы.
Если у powerdns есть прехуки (сейчас я стою в постхуке) то можно .ru домены завести на русский днс сервер. Тогда геоднс (route53) будет норм работать.
DoH поможет только при использовании нонейм серверов. Половину запросов на популярные dns типа гугла и клауда по ip перехватываются. И DoT просто отвратительно начинает работать, т.к. сертификат не проходит валидацию. DoH тоже нужно пускать через туннель.
Поскольку мне таких "выдающихся" доменов нужно немного, я решил у себя при помощи Conditional Forwarding в bind.
Вкратце:
На VPN поднимаем кэширующий bind. В качестве доверенных клиентов указываем домашнюю сеть. Прикрываем ненужное файрволом
На домашнем bind в конфиг добавляем зону для нужного домена
В результате все устройства в домашней сети автомагически правильно резолвят. Не знаю, насколько хорошо такое масштабируется, но мне хватает
Большой набор рул в nft не загрузить потому, что nft работает через RT_NETLINK так, что туда много не влезает.
а зачем большой?
у меня берётся список сетей (примерно 18к строк) и загружается в два set'а (один для ipv4, второй для ipv6).
загрузка через nft -f занимает 0.2 с.
У меня меп который у них в примере https://github.com/pvxe/nftables-geoip для РФ в упор не хотел грузиться - говорил, что DATA TOO BIG
А почему не определять доступность сайта попыткой к нему подключиться? Подключаемся без vpn, получаем отказ, подключаемся по vpn и запоминаем, что по этому адресу нужно ходить через vpn. Если подключаемся по vpn, получаем отказ, подключаемся без vpn и запоминаем, что на этот айпишник нужно ходить без vpn. Если не вышло ни так ни так, сообщаем об этом пользователю (пишем в лог), и попытки подключения прекращаем.
Да, первое подключение будет дольше, чем обычно, но не всегда. Но так можно обойтись без всякой геолокации, ручных списков и т.д.
Или я чего-то не понимаю?
upd: Всё это, конечно, при условии, что цель — зайти на сайт, а не скрыть своё местоположение, дополнительно себя защитить и т.д.
Это можно делать когда через SQUID подключаешься и именно так я сделал в первую очередь. Хотя, там списки кстати тоже нужны. hashicorp и клаудфронт возвращают 403. Но есть сайты, которые просто показывают текст без http ошибки - их только руками.
Почему я от SQUID отказался - там выше написано.
Но, если и без сквида делать, то тогда не получится вообще. Потому, что SNI в TLS v1.3 - зашифрован, и по пути банально никто не знает на какой сайт происходит подключение. Помимо этого, нужно вклиниться в TCP сессию, чтоб клиент продолжил работать после переподключения - это не так-то просто. Объем кода для перехвата HTTP сессии в режиме MITM - он гораздо выше чем то, как сделано. А если мы хотим через SFLOW перехватывать, то там еще на порядок больше работы.
Можно прикрутить кстати какой-то плагин для браузера или расширить прокси-автосвитчер. Но, всё это началось с того, что у меня на одном из компов не работал terraform init :) а тут плагин для браузера не пойдет.
А почему не определять доступность сайта попыткой к нему подключиться?
Как минимум потому, что многие сайты отдают результат, иногда даже с успешным кодом. Просто на экране - "извинити, мы не можем вам предоставлять услуги, вот вам ссылка с подробностями".
Различные (удачные и нет попытки).
Может, лучше так:
Различные (удачные и нет) попытки.
?
Для сайтов я пользуюсь расширением "Обход блокировок Рунета" в режиме "Только свои сайты и свои прокси". Соответственно, прокси на удаленном сервере (хотя можно и купить чисто прокси)
Для конкретных приложений - Windscribe VPN с включенным режимом Split Tunneling (Inclusive)
На телефоне - AdGuard + Shadowsocks в режиме прокси (включается при необходимости через flow в Automate)
Есть довольно простое решение, которое работает по доменам - https://en.wikipedia.org/wiki/Proxy_auto-config
Файл хостится на домашнем сервере/роутере/удаленном сервере/или даже локально на компьютере.
Нужные домены роутит через свой прокси, остальные - напрямую. Прокси может работать в докер контейнере с wireguard-only egress.
Бороться надо не со следствием, а с причиной.
Я таким "умным VPN" уже много лет пользуюсь, называется Антизапрет :)
возникла потребность более умного VPN, который русские сайты отправит по одному маршруту, а не-русские - по другому
Простейшее решение - банальный HTTP/HTTPS Proxy, который можно задать в браузере (глобально или в отдельном профиле). Бесплатных - море, но очень нестабильны. Казалось бы, у каждого VPN-провайдера должны быть такие серверы с авторизацией, но увы.
Банальный прокси не сможет увидеть имя сайта в HTTPS-соединениях, а потому бесполезен для этой задачи.
Для этого есть автоматическая настройка прокси, которой управляет браузер - https://en.wikipedia.org/wiki/Proxy_auto-config .
PAC — это, конечно, решение, но оно несколько отличается от предложенного выше "банального HTTP/HTTPS Proxy".
несколько - да, но не принципиально.
Отличие принципиальное. Прокси — это прокси, а PAC — это механизм для выбора прокси. Они никак не являются взаимозаменяемыми.
Отличие принципиальное. Прокси — это прокси, а PAC — это механизм для выбора прокси. Они никак не являются взаимозаменяемыми.
PAC не заменяет прокси - он дополнительный инструмент решающий озвученную Вами проблему "Банальный прокси не сможет увидеть имя сайта в HTTPS-соединениях, а потому бесполезен для этой задачи"
Можно на уровне PAC прописать прямой доступ для доменов в зоне RU + крупные российсикие сервисы, а остальные отправлять на прокси. И никакой https этому не мешает.
Если Вы внимательно перечитаете эту ветку, то увидите, что речь изначально была именно об этом и ни о чём более.
А давайте вы внимательно перечитаете ветку?
Перечитываю.
Вы пишете: " Банальный прокси не сможет увидеть имя сайта в HTTPS-соединениях, а потому бесполезен для этой задачи. "
Я пишу: " Для этого есть автоматическая настройка прокси, которой управляет браузер - https://en.wikipedia.org/wiki/Proxy_auto-config . "
Дальше Вы начинаете спорить с выдуманной Вами же идеей о замене прокис на PAC.
А вы читайте комментарием раньше, и в контексте поста.
Автор пишет: "мне нужен механизм переключения между InnerNet и OuterNet".
emusic пишет: "для этого можно использовать … прокси".
Я ему пишу: "прокси сам по себе не может быть решением проблемы автора, нужно что-то ещё"
И тут вы начинаете говорить про PAC. Ну да, PAC является одним из вариантов, который бы мог помочь автору. Но как, блин, это отменяет тот факт, что прокси сам по себе не может быть решением проблемы автора?
Если первый squid поднять локально, то до не заблокированных сайтов получится вообще прозрачно. А список доменов можно подтягивать простым wget-ом как раз с забугорного squid-а.
Получается быстро, но уже не работает с некоторыми сайтами. Дальше, я полагаю, ситуация будет только ухудшаться, по мере роста усердия РКН.
А вот HTTPS прокси я не осилил. После дня гугления так и не понял, существуют ли они вообще, или это только MITM-ы.
Ну разумеется, чистый HTTP может. Проблема только в том, что уже 10 лет как весь интернет переходит на HTTPS.
А вот при проксировании HTTPS используются не обычные методы HTTP, а метод CONNECT. Поэтому единственный способ "заглянуть" внутрь и что-то сделать — это терминировать TLS на стороне прокси. Да, прокси становится при этом MITM.
У меня больше года все сайты ходили через HTTP прокси, в черном списке были только несколько сайтов, которым
Я так понимаю, почти все прокси серверы уже умеют CONNECT. Кроме, например, nginx. Для него нужен патч.
3proxy и squid точно умеют гонять HTTPS работая при этом через HTTP.
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 через прокси загружается, а вот фото и видео уже нет. Чудеса.
Для этой задачи (с отдельным профилем браузера) прокси-серверу нет необходимости что-либо "видеть". А задачи разделять трафик между множеством путей не ставилось.
В смысле — не ставилось? А это тогда что:
возникла потребность более умного VPN, который русские сайты отправит по одному маршруту, а не-русские — по другому
Вот я и описал простейшее решение - браузер с двумя профилями (в двух экземплярах), плюс мозг, который для русских сайтов использует один экземпляр, а для остальных - другой.
Но, конечно, если очень хочется в гамаке на лыжах, то можно возиться и автоматизированными решениями. Но они все равно не будут 100% автоматическими, поскольку конфигурацию придется регулярно допиливать.
Как по мне гораздо проще PBR на базе GeoIP плюс отдельный белый список для выдающихся кто сидит на зарубежных адресах и пускает только с русских. Я не думаю что их очень много.
Когда столкнулся с таким, решил, что список нужных росс. ресурсов, недоступных извне, конечен, а список недоступных внешних ресурсов, потенциально бесконечен.
Хотел найти список таких ресурсов, но почему-то не нашёл и создал свой https://github.com/shredder2003/russianNoVPNservices/blob/main/hosts.csv
А дальше ещё и программку, которая по списку ресурсов проходится, и в роутер забивает маршруты по этим ресурсам. Два месяца использую - проблем нет.
ну как минимум отзывчивость сайтов страдает.
Проблема такого подхода — всевозможные CDN, добавлять их вручную на каждое изменение — процесс печальный.
А на тему цепочек — есть хорошая картинка, которая показывает путь пакетов в мозгах микротиков:
https://www.mikrotik-trainings.com/trainings_files/docs/MikroTik_PacketFlow_Routing24.jpg
Прошу прощения, второй абзац должен был быть не сюда...
CDN - речь про то, что на одно доменное имя могут в случайном порядке выдаваться разные IP? Если про это, то да, насколько помню, mos.ru такой. И да, вручную добавлять-обновлять неприятно, потому и написал программу, которая сначала делает 20 резолвов имени, затем на все полученные IP маршруты создаёт. Таким образом, если что-то перестало работать, достаточно запустить программу ещё раз, она дорезолвит недостающие IP и пропишет их в маршруты роутера (Keenetic).
Задача решена эффективно и конкретно под Россию на голову выше предлагаемых альтернатив: 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 ← ?
Обычная способ маршрутизации также применяется, но только для больших диапазонов заблокированных адресов (всего несколько маршрутов).
Маршрутизируются только заблокированные домены, а не все сайты на заблокированном IP-адресе;
сегодня всё чаще закрывают не из РФ, а от РФ, так что этого недостаточно. поддерживать и постоянно актуализировать список всех заблокированных с обеих сторон ресурсов — то ещё удовольствие.
я давно перевёл доступ ко всем иностранным хостам через VPN, на задержках до европейских/американских сайтов почти не сказалось (так и так трафик через европу идёт).
сегодня всё чаще закрывают не из РФ, а от
РФ, так что этого недостаточно. поддерживать и постоянно
актуализировать список всех заблокированных с обеих сторон ресурсов — то
ещё удовольствие.
Для этого существует разделение на distro-список, который поставляет автор контейнера, и custom-список, который пользователь может редактировать самостоятельно.
К тому же, это решение можно использовать и на стороне сервера, машрутизируя разные домены в разные VPN-каналы на сервере, а не на клиенте (у клиента один конфиг к одному серверу, а сервер сам решает, через какую страну маршрутизировать).
который пользователь может редактировать самостоятельно.
ну я про это и говорю «постоянно актуализировать»
К тому же, это решение можно использовать и на стороне сервера, машрутизируя разные домены в разные VPN-каналы на сервере, а не на клиенте
ну опять же нужен актуальный список доменов.
а тут один раз залил список ip-сетей и спишь спокойно (на самом деле обновление тоже настроил, но сначала несколько недель сидел без него, всё работало ровно так же; ip-сети не так уж часто выделяются/мигрируют)
Интересная модель с deterministic DNAT.
Зачем людям ранее был нужен 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/
Китайцы уже давно все сделали.
https://www.v2fly.org/en_US/
я с микротом забавно облажался.
Есть локальный 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 сервера, но смотрится как-то костыльно.
Очевидно, в правиле dst-nat следует ограничить интерфейс и/или маркировку маршрута, в зависимости от желаемого результата.
Так интерфейс по в любом случае LAN.
И перехватываться должны все DNS запросы, независимо от маркировки маршрута.
Если есть необходимость убрать NAT из DNS-трафика через VPN, то правило dst-nat позволяет выбрать условие !routing-mark. Это позволит исключить часть пакетов из dst-nat.
Если есть необходимость убрать DNS-трафик из VPN, то правило mangle prerouting позволяет выбрать условие dst-port. Это позволит исключить часть пакетов из таблицы to_vpn.
Есть желание убрать весь нешифрованный DNS наружу.
то правило mangle prerouting позволяет выбрать условие dst-port
Не получится, чтобы выбрать !dst-port нужно выбрать протокол, а мне нужно для всех протоколов.
Не получится, чтобы выбрать !dst-port нужно выбрать протокол, а мне нужно для всех протоколов.
В этом случае можно продублировать правило mangle цепочки prerouting, разместить его первым и выбрать в нём действие accept, чтобы пакет не проходил через другие правила mangle той же цепочки. В этом новом правиле следует указать дополнительное условие: протокол/порт UDP/53. Тогда пакет не получит маркировку маршрута.
При необходимости можно создать аналогично правило для запросов TCP/53.
Роутер, что у нас там дальше. Дальше у нас 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в таблице с максимальным приоритетом прописаны все локальные адреса.
но зачем?
а тем клиентам, которым надо использовать мой dns, я его через dhcp выдам.
Чтобы особо умные не использовали нешифрованный DNS.
не смотрел, что сделали в микротике, но в обычном линухе:
Поправьте если я ошибаюсь, но ведь там для случая когда надо перенаправить трафик НА адреса в ВПН.
Мне же надо пперенаправить трафик С адреса в ВПН
Покажите лучше эти правила экспортом конфигурации, будет понятнее.
Второй вопрос — а зачем вам вообще перехватывать 53 порт в DST_NAT, шлите его спокойно в тоннель по первому правилу с маркировкой.
5 ;;; 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, шлите его спокойно в тоннель по первому правилу с маркировкой.
Ну так тоннелю я не доверяю. не хочу туда нешифрованный трафик слать.
Я так понимаю, ваш микротик после получения пойманного пакета уже сам по безопасному протоколу стучится до выбранного вами DNS (94.140.14.14)? Если да — зачем вам правило 6 в том виде, в каком оно есть?
А на тему цепочек — есть хорошая картинка, которая показывает путь пакетов в мозгах микротиков:
https://www.mikrotik-trainings.com/trainings_files/docs/MikroTik_PacketFlow_Routing24.jpg
Ваша проблема в том, что mangle срабатывает до dst-nat. Соответственно, чтобы эти пакеты не ушли в другую таблицу — их нужно mangle правилом (перехватывающим весь 53 порт) достать в основную.
Если да — зачем вам правило 6 в том виде, в каком оно есть?
Всё именно так.
Правило 6 нужно для того чтобы вместо метки VPN, установилась метка по умолчанию main.
Именно такой вид ну просто так получилось. Если причесать то конечно там должен быть 53 порт, а дестинейшн IP фильтр.
Ваша проблема в том, что mangle срабатывает до dst-nat.
Нет моя проблема в Routing decision(хотя конечно если поменять местами dst-nat и mangle, то всё заработает). Почему он решает отправить в forward, а не в input?
Кстати у меня Ros 7.2.3. На ros 6 говорят направляет в input.
Соответственно, чтобы эти пакеты не ушли в другую таблицу
Я хотел бы смириться с тем, что отправляют в другую таблицу и отредактировать эту таблицу так, чтобы она работала корректно.
Почему он решает отправить в forward, а не в input?
Может быть интересно попробовать поменять в правилах для DNS action на dst-nat вместо redirect и указать целевой ip адрес роутера из нужной подсети. Просто redirect подставляет "какой-то" из адресов роутера и не обязательно нужный.
Это я проверял, IP подставляется нужный.
остановил гугленье на том, что в ROS6 это работает, а в 7-й версии нет.
отправил запрос баг ли это.
Возможно, ROS7 более vrf-aware, чем ROS6, и поэтому DNS-запрос, направленный в таблицу VPN, не найдя в ней указанный адрес назначения, перенаправляется по умолчательному маршруту наружу (соответственно, в цепочку forward). Хотя этот адрес принадлежит самому микротику в таблице main.
Если так, то это даже радует. VRF на ROS6 дюже дырявый.
nftables это тоже netfilter, непонятно почему вы им отказываете в родстве. И все это под капотом работает через bpf, который можно конфигурировать напрямую. И да, есть списки и это не map.
PS У меня схожим образом давно работает домашний роутер, только список маленький и статический и рефрешится по крону.
У меня схожим образом давно работает домашний роутер, только список маленький и статический и рефрешится по крону
Звучит как начало поста ?
ммммм. я не соглашусь. потому, что для NFT есть iptables-legacy. Таки это другая организация в ядре.
NFT не мог решить одну из этих двух задач (в принципе не мог) :
у нас есть два айпи и два интерфейса (без бонда) в одной подсети с одинаковой метрикой.
мы по какому-то принципу, натим пакеты либо в один либо в другой.
И там было по-моему так : исходящий пакет не всегда (что-то одно, что точно - не помню) :
выходил с нужного интерфейса.
выходил с нужным маком.
выходил с нужным ипом.
т.е. связка : исходящий интерфейс - мак - айпи не всегда в такой ситуации была корректной. Я перепробовал всё - от ebt и PBR до ipt. и только на NFT я решил с пол пинка.
Организация в ядре одна и таже что у ipt, что у nft и, внезапно, у tcpdump. Это BPF. По крайней мере в актуальных линуксах. Все эти фильтры развивались командой netfilter и, со временем, сверху остались только бэкэнды к общей подсистеме ядра, для сохранения совместимости и User experience. Причём прошу не путать новый bpfilter с собственно подсистемой BPF. Это тоже бэкэнд. Вы его можете ставить или не ставить, а подсистема есть всегда.
Что касается вашего примера, то пакеты помечаются в принципе одинаково что в nft, что в ipt, видимо какая то минорная ошибка у вас была.
У меня наоборот возникли проблемы с nft, пока я не полез в код и не сравнил приоритеты хуков с их вики. Отписал, в вики поправили.
В nft есть трейсинг, удобно отлаживать правила.
Перерыв многое лучше Proxifier не нашел. Это для Windows и Mac
По результатам обсуждения возник вопрос: если Вы рассматривали "старый добрый squid" и готовы возиться с настройками, то не проще ли использовать на стороне браузера Proxy Auto Config ( например, https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_PAC_file ) , чем внедрять корневые сертификаты?
Не только браузеру же нужно. Обычно бывает ооочень много приложений помимо браузера : всякие IoT устройства, ну и другие прилы, которые не пользуются браузером. Тот же телеграм.
А можете рассказать как работает антифильтр BGP?
На сколько я понимаю BGP устанавливает маршрутизацию с соседними роутерами, т.е. в данном случае запрос на заблокированный ресурс пойдет через роутеры антифильтра?
нет, вам всё так же нужен будет vpn, куда вы сможете завернуть трафик до проблемных сетей.
bgp исключительно обменивается информацией, необходимой для построения таблицы маршрутизации, то есть снимает с вас задачу периодической актуализации списка заблокированных сетей (это всё равно нужно делать, но этим будет заниматься-то кто-то другой, не вы).
Ок, сделали BGP соединение, пришла таблица маршрутизации - вот эти хосты заблокированы. Что пришлет BGP? Какой будет next hop для этих сетей из BGP?
это определяете вы (в конфиге bird, например).
вот пример bird.conf:
log syslog all;
router id 1.2.3.4;
protocol bgp antifilter {
neighbor 51.75.66.20 as 65444;
import filter {
gw = 10.20.30.40;
accept;
};
export none;
local as 64999;
hold time 240;
multihop;
}
protocol kernel {
import none;
export all;
kernel table 123;
}
protocol device {
scan time 0;
}1.2.3.4 — наш внешний адрес, с которым мы регистрировались на https://antifilter.network/bgp
10.20.30.40 — шлюз vpn
Я сначала пользовался Tor-ом, потом VPN-ом, в итоге пришёл к решению с Proxy PAC и Shadowsocks. По мере необходимости конкретные домены добавляю в proxy.pac.
Причём Shadowsocks и на смартфоне работает и на серваке ставитя очень просто.
Моя борьба с санкциями или как появился умный VPN