Как настроить маршрутизацию клиентов из LAN через VPN, а самого устройства через провайдера?

Question

[cherkunoff]

Добрый день!

В моей домашней сети есть Raspberry Pi, которую я хочу использовать в том числе как dns-резалку рекламы и как vpn-шлюз.

Для этих целей я установил AdGuard home и настроил на нём dns-over-tls, выпустив его в Интернет. Теперь реклама на мобильных телефонах режется не только при подключении к домашнему wifi, но и при использовании мобильной сети (в Андроиде есть штатные настройки для этого: Настройки -> Сеть и Интернет -> Персональный DNS сервер). Что бы всё работало, для определённого субдомена я настроил DNS запись типа A, указывающую на IP, получаемый от провайдера.

А вот с одновременным использованием Малинки как vpn-шлюза возникают проблемы. Для подключения к VPN я использую штатное приложение NordVPN под Linux и протокол Nordlynx (проприетарную реализацию Wireguard). Как только подключение поднимается, весь трафик уходит в туннель и я теряю доступ к dns-серверу AdGuard из Интернета. Сразу скажу, что настраивать DNS запись типа A на IP VPN провайдера не вариант - там все порты закрыты для входящих соединений.

Таким образом, мне нужно настроить следующую схему: трафик любого клиента из LAN (10.10.10.0/24), использующий Малинку как шлюз должен направляться через туннель с именем nordlynx, а трафик самой Малинки должен идти через провайдера.
Я понимаю, что мне нужен policy-роутинг (https://habr.com/ru/post/108690/), но как именно его настроить в такой конфигурации - пока догадаться не могу. В этой части и прошу помощи.

Моя текущая конфигурация.
Правило nat для интерфейа nordlynx:
-A POSTROUTING -o nordlynx -j MASQUERADE
Правила для цепочки FORWARD:

-A FORWARD -i eth0 -o nordlynx -j ACCEPT
-A FORWARD -i nordlynx -o eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Так выглядят таблицы маршрутизации без подключённого VPN:

$ ip rule
0:      from all lookup local
220:    from all lookup 220
32766:  from all lookup main
32767:  from all lookup default

Вот так - с включённым:

$ ip rule
0:      from all lookup local
217:    from all lookup main suppress_prefixlength 0
218:    not from all fwmark 0xca6c lookup 51820
219:    from all to <IP VPN провайдера> lookup main
220:    from all lookup 220
32766:  from all lookup main
32767:  from all lookup default

Так выглядят маршруты без VPN подключения:

$ ip route
default via 10.10.10.1 dev eth0 onlink
10.10.10.0/24 dev eth0 proto kernel scope link src 10.10.10.100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1

А так - с подключенным VPN:

$ ip route
default via 10.10.10.1 dev eth0 onlink
10.5.0.0/16 dev nordlynx proto kernel scope link src 10.5.0.2
10.10.10.0/24 dev eth0 proto kernel scope link src 10.10.10.100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1

Заранее благодарю за советы!

Answer 1

[cherkunoff]

Мне удалось решить проблему 2 способами. Дублирую свой же комментарий, что бы пометить его ответом - может, кому-то поможет. Первый подсказали на форуме и он делает в точности то, что я описывал в начальном сообщении с вопросом: перепускает трафик клиентов из LAN через VPN туннель, а трафик самой Малинки - через провайдера. Для этого нужно после подключения VPN добавить таблицу маршрутизации с правилом по-умолчанию пускать трафик через роутер и 2 правила для интерфейса lo:

ip route add to default via 10.10.10.1 table 100
ip rule add iif lo to 10.10.10.0/24 lookup main prio 16000
ip rule add iif lo to default lookup 100 prio 16010

Как выяснилось, существенный минус этого решения - это увеличение пинга с 4 до 120 мс. и падение скорости более, чем в 10 раз до провайдера. Это очень печалит.

Второй вариант решения задачи я нашёл, когда начал гуглить ради интереса про

not from all fwmark 0xca6c lookup 51820

Вот здесь описано решение: https://unix.stackexchange.com/questions/607004/ca...
Нужно добавить один маршрут:

ip rule add from 10.10.10.100 lookup main

Тогда трафик, идущий с IP провайдера сможет достигнуть Малинки.

Добавлять правила после подключения нужно потому, что в противном случае хитрый NordVPN подсмотрит их порядок и добавит свои правила перед ними.

Answer 2

[res2001]

Вам просто нужно на малинке добавить статический маршрут до вашего DNS провайдера, куда ходит AdGuard. Маршрут этот должен быть через DNS вашего оператора связи (или что там у вас сейчас в качестве шлюза по умолчанию без поднятого ВПН).
Никаких сложных телодвижений с настройкой фаервола не требуется.

Comments

[cherkunoff]

AdGuard на Малинке ходит до 6 провайдеров DNS параллельно (для ускорения работы). Я могу добавить маршруты для них, но не понимаю, что это даст. У меня такая ситуация:
1. Если VPN выключен, то Малинка работает как DNS-сервер как внутри локальной сети, так и для внешних клиентов из Интернета, которые подключаются к ней по адресу типа mydns.mydomain.com. У mydns.mydomain.com есть запись типа A, которая отравляет на IP, выданный провайдером; на моём роутере (через который Малинка и все устройства выходят во вне) настроена переадресация портов на Малинку; в правилах firewall Малинки настроено принимать запросы на эти порты.
2. Если VPN включен, то Малинка продолжает работать как DNS-сервер, но только для локальных клиентов: то есть, она по-прежнему может получать адреса от DNS-провайдеров и отдавать их, правда теперь она это делает через VPN, но это частности. Но она перестаёт работать DNS-сервером для внешних клиентов из Интернет. То есть, я больше не могу обратиться к Малинке по адресу mydns.mydomain.com: ни к dns-over-tls, ни к веб-морде AdGuard.

Моя задача состоит в том, что бы при включенном VPN иметь возможность использовать Малинку из Интернета в качестве DNS-сервера, т.е. иметь возможность обратиться к ней по адресу mydns.mydomain.com

[shurshur]

cherkunoff,

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

Это позволит трафику до них ходить мимо VPN.

[res2001]

cherkunoff,

правда теперь она это делает через VPN, но это частности. Но она перестаёт работать DNS-сервером для внешних клиентов из Интернет.

Эти частности как раз и не дают отдавать ответы DNS внешним клиентам. Если вы запустите трафик DNS в обход ВПН (на прямую), то все у вас должно заработать так как вы хотите.

[res2001]

cherkunoff, Кстати, присоединяюсь к вопросу AUser0 - судя по таблице маршрутизации после подключения к ВПН шлюз по умолчанию у вас не меняется. А значит трафик клиентов не идет через ВПН.
Как вы направляете внутренних клиентов через малинку?

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

[cherkunoff]

res2001, для теста убрал все DNS, кроме 1.1.1.1 из Adguard (что бы не прописывать много маршрутов) и прописал маршрут сначала через мой роутер (10.10.10.1) - через него в Интернет ходит Малинка (10.10.10.100) и все клиенты LAN. Со включенным VPN получились вот такие маршруты:

$ sudo ip route list
default via 10.10.10.1 dev eth0 onlink
1.1.1.1 via 10.10.10.1 dev eth0
10.5.0.0/16 dev nordlynx proto kernel scope link src 10.5.0.2
10.10.10.0/24 dev eth0 proto kernel scope link src 10.10.10.100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1

Тот, который "10.5.0.0/16 dev nordlynx..." - добавляется приложением NordVPN при подключении и удаляется после отключения.

Это не сработало. AdGuard из вне не доступен.

Попробовал также не через явное указание шлюза, а через интерфейс eth0:

$ sudo ip route
default via 10.10.10.1 dev eth0 onlink
1.1.1.1 dev eth0 scope link
10.5.0.0/16 dev nordlynx proto kernel scope link src 10.5.0.2
10.10.10.0/24 dev eth0 proto kernel scope link src 10.10.10.100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1

Также не помогло.
При этом, как только я прописываю маршрут, AdGuard перестаёт получить результаты запросов от 1.1.1.1. nslookup выдаёт ошибку: "*** UnKnown не удалось найти <адрес любого сервера не в кэше>: Server failed"

Прямо через шлюз провайдера прописать маршрут нельзя: "Nexthop has invalid gateway".

По поводу того, как клиенты ходят через малинку - я отвечу сейчас в ветке тов. AUser0, что бы не разбивать ветки.

Answer 3

[AUser0]

Что-то не видно, каким образом весь трафик клиентов, использующих Малинку как шлюз, направляется в VPN.
Ещё более странным выглядит ip rule 217: from all lookup main suppress_prefixlength 0, которое просто повторяет стандартное правило 32766: from all lookup main.
Либо в случае VPN-соединения routes выглядят совсем по другому, либо что-то еще. Потому что вот с этой конфигурацией клиенты из Интернета должны спокойно получать доступ к DNS. Может что-то есть в iptables?
А что даёт ip route show table 220?

Comments

[cherkunoff]

Сейчас расскажу. Сразу скажу, я не профессионал в настройке сетей - поэтому и купил Малинку, что бы поучиться для своего удовольствия. Часть того, что я сделал - это компиляция инструкций из Интернета (с осмыслением). Таким образом, применённые решения могут быть не оптимальными. Моя же задача - понять, как работает сеть не на уровне "воткнул 3 провода в роутер и прописал настройки по бумажке", а не более продвинутом уровне. Ну и настроить сеть как хочется.

Схема сети:


ТВ приставка висит на отдельном, обособленном интерфейсе (и ip у неё из другой подсети - это не ошибка), что бы не пускать multicast траффик в LAN. Надеюсь, правила firewall на роутере для этого я настроил корректно.

Роутер - это ubiquiti ER-12. 8 портов в switch0 + порт для ТВ-приставки + порт для провайдера. И ещё 2 SFP-порта остались свободными: на будущее.

По-умолчанию DHCP сервер роутера выдаёт значение шлюза = IP роутера. Таким образом, все клиенты ходят в Интернет через него и через провайдера.
На Малинке установлен приложение NordVPN, создающее туннель с именем "nordlynx".

Что бы можно было использовать малинку в качестве шлюза я воспользовался инструкцией https://www.instructables.com/Raspberry-Pi-VPN-Gateway/ и прописал в /etc/sysctl.conf настройку:

net.ipv4.ip_forward = 1

После чего прописал правило NAT и два правила в FORWARD (в изначальном сообщении они видны). Теперь, когда VPN на Малике подключен, любой клиент из LAN может сам, вручную указать в качестве шлюза адрес Малинки и завернуть трафик в туннель.

Что касается правила 217: его создаёт при подключении NordVPN самостоятельно, а после отключения - удаляет. Это видно из сравнения таблиц с включённым-выключенным VPN.

ip route show table 220 не даёт ничего: эта таблица пуста. Честно говоря, откуда она взялась - я не знаю.

Вообще говоря, приложение NordVPN крайне странное. В нём можно прописать свои белые листы (а-ля встроенный firewall). И при подключении оно автоматически создаст в начале таблиц INPUT и OUTPUT правила:

1. Разрешать соединения с IP VPN сервера.
2. Разрешать соединения, которые прописаны в настройках белого списка приложения
3. Отклонять все остальные соединения.

После отключения VPN оно эти правила удаляет. Или нет. Тут как повезёт. Если приложение вылетает или Малинка вырубается, правила приходится чистить руками.
И да, если не прописать в белый список адреса локальной сети (10.10.10.0/24) - после подключения к Малинке будет потерян доступ из локалки.
С моей точки зрения такое поведение мягко говоря неадекватно, если не сказать больше. Я написал в поддержку NordVPN с вопросом - как это отключить. Они сказали - никак. И посоветовали использовать Ipsec с помощью strongwan.
Собственно вся возня с NordVPN связана с тем, что их протокол nordlynx (проприетарный wireguard) выдаёт наилучшую скорость на Малинке. Так что пока я просто написал небольшой bash-скрипт, который вызывает подключение NordVPN, затем переписывает iptables моими правилами.

[res2001]

cherkunoff,

После чего прописал правило NAT и два правила в FORWARD

Правила FORWARD принудительно направляют весь трафик через ВПН, поэтому не работает маршрутизация так как нужно и поэтому отваливаются внешние DNS клиенты.
Что надо сделать:
1. NAT и FORWARD на малинке лишние - убрать. Большая часть HOWTO по настройке ВПН в интернете содержит рекомендации по настройке NATа. Но обычно нигде не говорится, что это не обязательно. Даже больше - в большинстве случаев это абсолютно не нужно. Но да, с NATом конструкция выглядит проще - не нужно настраивать другие компы в сети. Но часто дополнительная настройка тривиальна (а у вас ее вообще нет), но при этом избавляет от дополнительной не бесплатной манипуляции с IP адресами, которая отъедает процессорные ресурсы.
2. В NordVPN сделать настройку, устанавливающую шлюз по умолчанию через ВПН - обычно такая настройка есть в любых ВПН. Возможно понадобиться руками добавить маршруты к адресам NordVPN, но это не факт. Если после выставления шлюза по умолчанию после подключения, ВПН сразу будет обрываться, то надо.
3. Маршруты к DNSам оставить, как в первом варианте тут.
Так же нужно добавить правила FORWARD фаервола - перенаправлять трафик от AdGuard внешним клиентам через роутер. Фильтровать можно по локальному порту (DNS использует порт udp/53). Не скажу как это правило выглядит в iptables, т.к. мало с ним знаком.

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

PS: Большинство платных ВПН сервисов имеют какие-то свои специфические особенности, кроме того у большинства таких сервисов очень трудно чего-то добиться от поддержки.
Я предпочитаю арендовать обычный VPS с линуксом и на нем самому поднимать тот ВПН, какой больше нравится. Как правило использую OpenVPN.

[cherkunoff]

res2001, благодарю за советы. Я сделал следующее:
1. Удалил правила NAT и FORWARD, которые обеспечивали работу в режиме vpn-gateway ранее.
2. В группу FORWARD добавил вот такие правила, что бы перенаправлять трафик внешним клиентам:

У меня установлен докер - часть правил сверху от него. Последние три я добавил. 8459 - это порт, на котором висит dns-over-https и веб-морда AdGuard. По нему я и проверяю, есть ли доступ из вне.
3. В маршруты добавил маршрут до dns (1.1.1.1). Вот так они выглядят до подключения VPN:

$ ip route
default via 10.10.10.1 dev eth0
1.1.1.1 via 10.10.10.1 dev eth0
10.10.10.0/24 dev eth0 proto kernel scope link src 10.10.10.100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1

Подключаю VPN - маршруты изменяются на вот такие:

$ ip route
default via 10.10.10.1 dev eth0 onlink
1.1.1.1 via 10.10.10.1 dev eth0
10.5.0.0/16 dev nordlynx proto kernel scope link src 10.5.0.2
10.10.10.0/24 dev eth0 proto kernel scope link src 10.10.10.100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1

Что интересно - команда "ip route" показывает маршрут по-умолчанию через роутер (10.10.10.1). Но если выполнить команду "ip route show table all" - тогда будет виден ещё один маршрут по-умолчанию в таблице 51820! Как раз его похоже и добавляет приложение после подключения и благодаря ему трафик идёт через vpn. Почему он не показывается в ip route - не знаю.

$ ip route show table all
default dev nordlynx table 51820 scope link
default via 10.10.10.1 dev eth0 onlink
10.5.0.0/16 dev nordlynx proto kernel scope link src 10.5.0.2
10.10.10.0/24 dev eth0 proto kernel scope link src 10.10.10.100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
broadcast 10.5.0.0 dev nordlynx table local proto kernel scope link src 10.5.0.2
local 10.5.0.2 dev nordlynx table local proto kernel scope host src 10.5.0.2
broadcast 10.5.255.255 dev nordlynx table local proto kernel scope link src 10.5.0.2
broadcast 10.10.10.0 dev eth0 table local proto kernel scope link src 10.10.10.100
local 10.10.10.100 dev eth0 table local proto kernel scope host src 10.10.10.100
broadcast 10.10.10.255 dev eth0 table local proto kernel scope link src 10.10.10.100
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 172.17.0.0 dev docker0 table local proto kernel scope link src 172.17.0.1
local 172.17.0.1 dev docker0 table local proto kernel scope host src 172.17.0.1
broadcast 172.17.255.255 dev docker0 table local proto kernel scope link src 172.17.0.1

Трафик с Малинки идёт через Туннель, а AdGuard из вне не доступен.

Еесли переключиться на протокол OpenVPN - тогда маршруты начинают выглядеть так (тут они в "ip route" показываются):

$ ip route
0.0.0.0/1 via 10.8.3.1 dev tun0
default via 10.10.10.1 dev eth0 onlink
1.1.1.1 via 10.10.10.1 dev eth0
10.8.3.0/24 dev tun0 proto kernel scope link src 10.8.3.3
10.10.10.0/24 dev eth0 proto kernel scope link src 10.10.10.100
<IP VPN сервера> via 10.10.10.1 dev eth0
128.0.0.0/1 via 10.8.3.1 dev tun0
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1

При использовании OpenVPN AdGuard всё-равно не доступен.

[res2001]

cherkunoff,

default dev nordlynx table 51820 scope link

Предполагаю, что это проявление "множественных таблиц маршрутизации". Применяется, когда у вас, например, 2 выхода в интернет. В принципе их можно применить и для случая использования ВПН, почему бы и нет.
51820 - номер используемой таблицы маршрутизации.
Таблица маршрутизации по умолчанию имеет номер 0 и он не отображается.
Все пакеты попадающие в систему изначально маршрутизируются с помощью 0 таблицы.
Что бы пакет начал маршрутизироваться другой таблицей обычно средствами правил фаервола добавляют к нему соответствующую метку (номер таблицы маршрутизации). Пример можно посмотреть тут.
В вашем случае, видимо это правило фаервола загоняет пакеты в дополнительную таблицу маршрутизации:
not from all fwmark 0xca6c lookup 51820
Честно говоря, плохо понимаю, что оно означает :) Но явно lookup 51820 - это про таблицу маршрутизации.
Может быть, что правила фаервола, которые отправляют пакеты маршрутизироваться в таблицу 51820 находятся раньше правил FORWARD, которые вы добавили для DNS. Поэтому DNS трафик просто не доходит до этих правил. Ваши правила FORWARD надо поставить перед правилами NordVPN. Но скорее всего причина не работы DNS та, что описана ниже.

Почему у вас в правилах FORWARD для DNS указано

destination is 10.10.10.1

?
Это не верно. Destination должен быть - любой адрес (any) и destination port то же any, т.к. вы должны отвечать всем клиентам из интернета. А пока что ваш DNS отвечает только вашему шлюзу.

[cherkunoff]

Мне удалось решить проблему 2 способами. Первый подсказали на форуме и он делает в точности то, что я описывал в начальном сообщении с вопросом: перепускает трафик клиентов из LAN через VPN туннель, а трафик самой Малинки - через провайдера. Для этого нужно после подключения VPN добавить таблицу маршрутизации с правилом по-умолчанию пускать трафик через роутер и 2 правила для интерфейса lo:

ip route add to default via 10.10.10.1 table 100
ip rule add iif lo to 10.10.10.0/24 lookup main prio 16000
ip rule add iif lo to default lookup 100 prio 16010

Как выяснилось, существенный минус этого решения - это увеличение пинга с 4 до 120 мс. и падение скорости более, чем в 10 раз до провайдера. Это очень печалит.

Второй вариант решения задачи я нашёл, когда начал гуглить ради интереса про

not from all fwmark 0xca6c lookup 51820

Вот здесь описано решение: https://unix.stackexchange.com/questions/607004/ca...
Нужно добавить один маршрут:
ip rule add from 10.10.10.100 lookup main
Тогда трафик, идущий с IP провайдера сможет достигнуть Малинки.

Добавлять правила после подключения нужно потому, что в противном случае хитрый NordVPN подсмотрит их порядок и добавит свои правила перед ними.

UPD: По поводу решения, которое мы обсуждали выше. Я попробовал установить правило по-умолчанию раздела FORWARD в Accept, разрешив временно все соединения. После этого доступ к dns всё-равно не появился.