LINUX.ORG.RU
ФорумAdmin

Настроил роутинг в разные VPN целыми субдоменами, да по-разному для разных SSID, восторг.

 , , , ,


7

6

Захотел тревел-роутер с поддержкой Wireguard, да придумал такой приподвыверт: чтобы был двухдиапазонник и можно было на любом девайсе, хоть на Kindle, быстро пустить трафик через VPN или напрямую просто переключившись на другую сеть. Решил поддержать GL.iNet за идею продавать роутеры с OpenWRT из коробки и купил Slate. Да и железка реально понравилась, очень маленькая. Весит, правда, будто большая.

Цель 0, обещанная: получить роутер, который может в Wireguard по переключателю

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

Цель 1, оригинальная: разный роутинг для разных SSID

Задача вроде несложная: разделяем Wi-Fi сети на два несвязанных интерфейса, заводим две подсети и две таблицы роутинга. В фирменном интерфейсе ничего про две таблицы роутинга и близко нет, но по кнопочке Advanced в фирменном интерфейсе просто открывается luci… в которой тоже ничегошеньки нет про две таблицы роутинга. Зато интерфейсы и подсети разделяются чуть ли не drag-and-drop’ом. Вспоминаю, как, кажется, @intelfx жаловался, что в OpenWRT без ныряния в конфиги ничего серьезного не сделать, но сначала иду в гугл.

Из гугла тут же возвращаюсь окрыленный, ставить какой-то mwan3. Я, не разобравшись поначалу, ожидал просто возможность сделать несколько таблиц, а узрел целый, блин, менеджер аплинков с балансировкой, мониторингом, фейловером и вообще. Сочиняю в нем желаемые и (явно для его гибкости слишком примитивные) правила маршрутизации «разные source подсети - разные gateways» и получаю то, зачем вообще все это затеял: одна из Wi-Fi сетей роутится через VPN, а вторая — напрямую.

Цель 2, расширенная: отдельные правила для отдельных IP

До меня доходит, что можно заворачивать в VPN трафик для отдельных хостов по destination IP. Получается, что для них трафик можно принудительно гонять через VPN, или наоборот, принудительно напрямую, и части ручных переключений можно будет избежать. И правила эти можно писать раздельно для двух SSID. Красота, причем все это все еще в пределах luci, ни одного конфига все еще не пострадало.

Цель 3, немыслимая: заворот по имени вместо IP

Оказывается, что в этом mwan3 правила можно применять по ipset: динамическому множеству destination IP. А dnsmasq умеет загонять в эти множества айпишники на основе доменного имени прямо по мере резолвинга. То есть пока на моем устройстве DNS’ом указан мой роутер, можно написать правило «а на все IP, застуканные за обслуживанием somesite.com и всех его поддоменов (!) распространить такое-то правило роутинга». Для написания этих правил, внезапно, тоже есть готовая морда для luci, но в репах ее не нашлось, а README на китайском отпугивает меня достаточно, чтобы я забил и просто написал их в пустой /etc/dnsmasq.conf руками.

Цель 4, че уж там: несколько VPN

Ну и нечего ограничиваться одним VPN и двумя подсетями с разными правилами, если можно N VPN и K<5 подсетей. Прописал еще один VPN для ходьбы наоборот, через Россию, добавил новых ipset’ов и правил роутинга.

Теперь /etc/dnsmasq.conf состоит из записей типа:

ipset=/some_banned_website.com/force_nl
ipset=/some_other_website_banned_in.ru/force_nl
ipset=/one_more_site.ru/prefer_nl
ipset=/accessible_only_from.ru/force_ru
ipset=/whatismyip.com/force_direct

На этом этапе был, правда, подводный камень: когда уже подключен VPN1 и подключается VPN2, автопрописыватель статического маршрута до endpoint от VPN2 какого-то лешего прописывал его через VPN1. В итоге трафик радостно бегал, например, из России в Голландию, обратно в Россию и только потом к адресату. Логику автопрописывателя выяснять было лень и я написал скрипт, который после поднятия VPN-интерфейсов просто удаляет такие идиотские маршруты. Скорее всего я сам дурак себе грабли подложил и можно было гораздо проще.

Итог

После всех этих манипуляций я могу заворачивать трафик в нужный VPN или пускать его напрямую целыми поддоменами + имею возможность переключаться между двумя такими наборами правил с разными дефолтными маршрутами просто выбрав нужную Wi-Fi сеть, на любом устройстве. Может можно и еще круче, но все упирается в мою фантазию, которая уже полпоста как безнадежно отстает от возможностей. По мере набухания моих хотелок я все-таки залез в конфиги и даже скрипт написал, но 1) возможно я просто поленился понять, как это делается правильно, и, вообще-то, 2) это было уже для достижения того, чего я не только не планировал, я вообще не думал, что так можно. Отсюда

резюме: OpenWRT — торт, luci — торт, mwan3 — торт, dnsmasq — торт, wireguard — торт, GL.iNet — красавцы, линукс готов для потребительских роутеров с уровнем потребителя от одноклеточных до меня включительно, я просто в восторге.

★★★★★

А аплинк оно откуда берёт?

Я, не разобравшись поначалу, ожидал просто возможность сделать несколько таблиц

Для этой возможности mwan3 и не нужен. А у него что, гуй какой-то есть или чем вообще он тебе понравился?

@intelfx жаловался, что в OpenWRT без ныряния в конфиги ничего серьезного не сделать

Да фиг с ними с конфигами, там в код нырять приходится раз через три. Хорошо ещё если код на шелле.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)

Я пошел дальше, и написал свой DNS-ремаппер, который устанавливает соответствие полученного IP-адреса с домена в адрес из большой приватной подсети, через iptables dnat. Таким образом могу динамически настраивать маршрутизацию по доменам на стороне VPN-сервера.

ValdikSS ★★★★★ ()
Ответ на: комментарий от intelfx

А аплинк оно откуда берёт?

В смысле роутер вообще? Меня интересовал только WAN-порт, но производителем заявлены еще варианты с Wi-Fi в режиме станции, USB-модемами и tethering’ом с мобилкой.

Я, не разобравшись поначалу, ожидал просто возможность сделать несколько таблиц

Для этой возможности mwan3 и не нужен.

Ясное дело, если достать ssh и закопаться в кишки-потрошки инициализации и конфигурации OpenWRT, в которых я ничего не смыслю и смыслить не хочу.

А у него что, гуй какой-то есть или чем вообще он тебе понравился?

Да, я его поставил в общем-то только чтобы правила строчить прямо из luci, все его балансировки нагрузки, временные привязки клиентов к аплинку, мониторинг я не использую, только гуй и совсем слегка failover. Ну и без него и его гуя я бы может и не узнал про роутинг по ipset и интеграцию с dnsmasq.

Да фиг с ними с конфигами, там в код нырять приходится раз через три. Хорошо ещё если код на шелле.

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

t184256 ★★★★★ ()
Ответ на: комментарий от ValdikSS

Я, кстати, когда писал про отстающие хотелки как раз вспомнил тебя и твои достижения по автоматизации борьбы с нашими новыми досадными реалиями.

Поясни, плиз, смысл своего финта ушами. DNS-ремаппер один централизованный на все девайсы? Я правильно понимаю, что трафик до всего, что он в эту подсеть завернет, придется гнать через какой-то один VPN и уже оттуда маршрутизировать через другие?

t184256 ★★★★★ ()
Ответ на: комментарий от intelfx

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

Плюс, боюсь, ближайшее время интернета быстрее ста мегабит у меня все равно не будет, и упереться в его пропускную способность я толком и не смогу.

t184256 ★★★★★ ()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от t184256

DNS-ремаппер запускается на VPN-сервере (а не на VPN-клиенте, как у вас), и предназначен для проксирования ТОЛЬКО определенных доменов, в отличие от вашего подхода.

Работает он следующим образом:

  1. VPN-клиенту, подключенному к серверу антизапрета, отдается маршрут на 192.168.104.0/22 (и больше ничего). Клиент пытается зайти на rutracker.org. Выполняется разрешение имени rutracker.org.
  2. DNS-сервер на VPN-сервере получает запрос на резолв rutracker.org, выполняет его, получает от DNS-сервера сайта ответ: 195.82.146.214
  3. DNS-сервер на VPN-сервере понимает, что rutracker.org заблокирован, и запускает: iptables -t nat -I PREROUTING -d 195.82.146.214 -j DNAT --to 192.168.104.1, где 192.168.104.1 — свободный (неиспользуемый) IP-адрес в 192.168.104.0/22.
  4. DNS-сервер, в ответ на запрос rutracker.org в пункте 1, возвращает клиенту 192.168.104.1.
  5. Клиент открывает rutracker.org через 192.168.104.1, через VPN.

Преимущество в том, что не требуется отправлять кучу маршрутов клиенту, и что менять конфигурацию «маршрутизации» можно без переподключения клиента.

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

ValdikSS ★★★★★ ()
Ответ на: комментарий от ValdikSS

Спасибо за детальное расписывание, очень интересно.

и предназначен для проксирования ТОЛЬКО определенных доменов, в отличие от вашего подхода

Так у меня тоже получается, что (для одной из сетей) в туннели уходят запросы только на соответствующие ipsetы.

менять конфигурацию «маршрутизации» можно без переподключения клиента

Так у меня тоже конфигурация маршрутизации меняется просто по добавлению в ipset.

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

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

Однако предвижу пару минусов в ее натягивании конкретно на этот свой сетап.

  1. Чтобы поддерживалось N VPN, нужно будет N таких подсетей, один резолвер и механизм добавления правил от разных туннелей на N разных endpoint’ах. Ну или гонять трафик через лишний крюк.

  2. Чтобы поддерживались разные конфигурации на клиентах за разными SSID нужно будет натравить из на разные резолверы, запустить эти разные резолверы и как-то синхронизировать их деятельность в правилах iptables, чтобы они и друг другу на пятки не наступали, и DNS caching на клиенте не мешал мне переключаться.

Только из-за них не рвусь перенастраивать роутер и сервер на эту схему. Возможно стоит для подключений к VPN с ноутбуков и телефонов реализовать эту схему отдельно.

А где можно посмотреть на код твоего резолвера?

t184256 ★★★★★ ()
Последнее исправление: t184256 (всего исправлений: 1)