Werld

Посоветую не заниматься ерундой с контейнером, который вы, вероятно, установили с помощью приложения Amn...VPN со смартфона, так как эта штука не задумывалась для каких-то сценариев со сложной маршрутизацией. Предлагаю вернуться к использованию wireguard, вы писали, что туннели работают. Если все-таки wg блокируют, то использовать awg, но без контейнера, а с ядерным модулем. Устанавливается используя короткую инструкцию прямо из их репозитория на гитхаб. Там все не сложно, с нейросетью справитесь. Если на сервере debian 13, то подключая по той инструкции репозиторий, измените https://ppa.launchpadcontent.net/.../ppa/ubuntu focal main на https://ppa.launchpadcontent.net/.../ppa/ubuntu noble main. Кроме того не все пакеты предустанавливаемые по инструкции - существуют для debian13, например, нет software-properties-common - это нормально, ставите что есть, идете дальше. Для debian 12 ничего менять не надо. Для ubuntu инструкция вполне актуальна. Все написанное далее должно быть актуально как для wg так и для awg. Рекомендую поднимать wg/awg с помощью wg-quick (соответственно awg-quick), тогда и маршруты нужные добавятся и можно заставить стартовать интерфейс с загрузкой системы (systemctl enable wg-quick@wg0). На сервере у вас будет два интерфейса один для соединения с кинетикомРУ, второй для соединения с кинетикомУЗ. Допустим адреса: КинетикРу 10.8.5.2/29-->wg0(10.8.5.1/29)<Сервер>wg1(10.8.5.100/29)<--КинетикУз(10.8.5.101/29). С адресами и масками внимательно, сети не должны пересекаться. На кинетикеРУ allowed ip = 0.0.0.0/0 На сервере: Интерфейс wg0 (куда подключается кинетикРУ): [Interface] Address = 10.8.5.1/29 ListenPort = Порт, который нужно открыть в фаерволе. PrivateKey = key1 [Peer] #KeeneticRU PublicKey = pubkey_from_KeeneticRU AllowedIPs = 10.8.5.2/32 --------- Интерфейс wg1 (куда подключается КинетикУЗ) тут посложнее: [Interface] Address = 10.8.5.100/29 ListenPort = Порт, который нужно открыть в фаерволе. PrivateKey = key2 Table = 1000 PostUp = ip rule add from 10.8.5.2 table 1000 PreDown = ip rule delete from 10.8.5.2 table 1000 [Peer] #KeeneticUZ PublicKey = pubkey_from_KeeneticUZ AllowedIPs = 0.0.0.0/0 --------- С таким конфигом wg1 система сама создаст таблицу 1000, поместит в нее маршрут по умолчанию через wg1, А дополнительные правила PostUp добавят правило маршрутизации. На кинетикеУЗ убрать галочку использовать для выхода в интернет. На кинетикеУЗ allowed ip = 10.8.5.2/32, 10.8.5.100/32 На кинетикеУЗ оставить правила в межсетевом экране, разрешающие входящие с адреса 10.8.5.2 на интерфейсе wireguard. На кинетикеУЗ добавить нат ip nat WireGuardx. На кинетикеУЗ придется добавить маршрут до 10.8.5.2 через интерфейс Wireguard. Описаная схема подразумевает выход для клиентов с КинетикаРУ в интернет за КинетикомУЗ. В обратную сторону идут только ответные пакеты. Выход для клиентов КинетикаУЗ в интернет за КинетикомРУ не предусмотрен. Доступ клиентам КинетикаРУ к домашней сети КинетикаУЗ не предусмотрен. Пробуйте. Возможно, что-то забыл упомянуть, так как давно уже такое не настраивал, писал из головы. Особенно касется КинетикаУЗ, возможно что-то для него еще упустил.

Почему на кинетике адрес 10.77.0.2/32? Он тогда не имеет маршрута до 10.77.0.2. Проверьте в веб-интерфейсе кинетика пинг до 10.77.0.2. Скорее всего его не будет. Нужно маску сделать 24, раз такую выбрали. И еще на кинетике в узбекистане security-level на интерфейсе wireguard1 какой? Если он Public - надо разрешающие правила в межсетевом экране добавить.

Peer1......Peer2 h1 = h1 ≠ ≠ h2 = h2 ≠ ≠ h3 = h3 ≠ ≠ h4 = h4

ls -ilh /tmp/hosts /var/hosts 1213 -rw-r--r-- 1 root root 34 Jan 1 1970 /tmp/hosts 1213 -rw-r--r-- 1 root root 34 Jan 1 1970 /var/hosts ls -lh /var lrwxrwxrwx 1 root root 4 Jun 6 23:18 /var -> /tmp

Раз ipset list bypass выводит список адресов, значит он наполняется. Вы можете выполнить ipset flush bypass - это очистит указанный ipset. ip rule выведет правила маршрутизации, где вы должны увидеть вашу таблицу, например: ~ # ip rule | grep 1001 1776: from all fwmark 0x3e9 lookup 1001 ip route list table 1001 должен показать наличие маршрута по умолчанию через нужный интерфейс. iptables-save | grep bypass должен показать два правила осуществляющие маркировку. Если все на месте, то все должно работать.

Наоборот, 5353 лучше не использовать. Диагностировать поэтапно. Проверяете создана ли таблица маршрутизации. Существует ли ipset. Наполняется ли он. На месте ли правила iptables. Естиь ли в созданной таблице маршрутизации маршрут по умолчанию и т.д.

Не знаю. Мне кажется, это ни к чему. Скриптовая обвязка от этого не изменится.

Ну да.Оба ipset'a должны существовать. Должно быть две таблицы, с разными номерами. В каждой должен быть маршрут по умолчанию через нужный интерфейс. Трафик для попадания в разные таблицы должен маркироваться разными метками.

В вашем случае просто прописываете все домены на один и тот же адрес и порт dnsmasq'a. А уже в конфиге dnsmasq.conf создаете две строки для двух ipset в каждый свои домены: ipset=/ytimg.com/bypass ipset=/intel.com/bypass2

Очевидно как-то не правильно вы пишете дефолтный маршрут в таблицу. Определите корректный шлюз по умолчанию для этого интерфейса и скорректируйте скрипт 010-bypass-table.sh Как-то так: ip route add default via 172.20.20.1 table 1001 Либо, как вариант, вы можете использовать частично способ из темы про AdguardHome. Не создавать таблицу и маршрут самостоятельно. А просто создать через веб роутера новую политику, сделать в ней единственным подключением ваш WISP. Роутером будет создана таблица маршрутизации для определенной метки. Вам останется лишь подкорректировать скрипт /opt/etc/ndm/netfilter.d/010-bypass-netfilter.sh , чтобы трафик маркировался меткой нужной для этой таблицы:

Ранее в этой теме, автор выкладывал удобный скрипт для отлавливания всех событий в хуках

Переехать в /opt/etc/ndm/iflayerchanged.d Я использую переменные "${layer}-${level}" При включении wg отлавливаю "${layer}-${level}" == "link-running" При отключении руками "${layer}-${level}" == "link-disabled" Все работает. Если пир отваливается, но сам интерфейс на роутере включен, то переменная level переходит в состояние pending и так и висит. Я это не использую, но может вам пригодится

Большое спасибо за готовую к работе обвязку для tpws. Я для себя адаптировал, т.к. не пользуюсь ipv6. Как пишет сам автор, tpws, очевидно, не поможет с quic, а т.к. приложение YT для AndroidTV, например, использует его, то для меня это актуально. У того же автора есть nfqws, которая помогает в том числе и с quic. Но с ней есть некоторые сложности на кинетике, я не стал вникать, решил добить работу через tpws. В общем-то решение простое, можно заблокировать доступ к udp:443, что не позволит устройствам использовать https3/quic и вынудит их откатиться на обычный https. Правилo сделал максимально точным, чтобы не ломать https3 там где мне не нужно Все вроде работает. У меня кн1910, при просмотре очень тяжелого 4k hdr нагрузка на процессор периодически подскакивает но в среднем нагрузка от несущественной, до едва заметной)

Никто не запрещает использовать nano 😊.

Возможно кто-то, как и я, использует AdGuardHome в качестве основного днс-резолвера, но установлен он на отдельном устройстве в сети, например на одноплатнике. В таком случае, все равно возможно использование ADGH вместе с кинетиком для выборочного доступа к заданным доменам. На кинетике с помощью entware нужно поднять резолвер с возможностью складывать результаты в ipset. Поднимать еще один ADGH, думаю, глупо, так что можно воспользоваться dnsmasq или ipset-dns. ADGH умеет обращаться к апстрим серверам на нестандартный порт, и резолвер на кинетике для этой цели может крутиться на свободном порту не требуя opkg dns-override, а значит оставляя не тронутым прошивочный для, например, работы в других сегментах сети. Сам использую dnsmasq с простейшим конфигом, где указано кроме прочего : port=40 cache-size=0 #т.к. кеширует сам ADGH ipset=/#/bypass Домены очень удобно указывать прямо в интерфейсе AdGuardHome. Просто как пример: Таким образом, на нужный порт роутера, где слушает dnsmasq, отправляются только заданные домены, результаты складываются в ipset. В остальном, все также, как расписано в этой теме, скрипты маркируют трафик и т.д. и т.п. Из бонусов то, что прошивочный dns не тронут, ADGH может ссылаться на него для резолва локальных хостов. А в качестве апстрима для dnsmasq, наверное, могут быть указаны прошивочные DoT или DoH.