Задать вопрос

cherkunoff

Комментарии

  • Как исправить очень медленный роутинг локального трафика при подключённом VPN?

    @cherkunoff Автор вопроса
    Попробую, но не могу сообразить, как задать условие "любой forwarded трафик"?

    По поводу Microtic, что бы не плодить веток я написал вот в этом комментарии: Как исправить очень медленный роутинг локального трафика при подключённом VPN?
    Написано

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

    @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 всё-равно не появился.
    Написано

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

    @cherkunoff Автор вопроса
    res2001, благодарю за советы. Я сделал следующее:
    1. Удалил правила NAT и FORWARD, которые обеспечивали работу в режиме vpn-gateway ранее.
    2. В группу FORWARD добавил вот такие правила, что бы перенаправлять трафик внешним клиентам:
    602ac8d28c5f2864849352.png
    У меня установлен докер - часть правил сверху от него. Последние три я добавил. 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 всё-равно не доступен.
    Написано

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

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

    Схема сети:
    60298821ee53f910911044.jpeg

    ТВ приставка висит на отдельном, обособленном интерфейсе (и 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 моими правилами.
    Написано

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

    @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, что бы не разбивать ветки.
    Написано

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

    @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
    Написано