Werld
-
Постов
465 -
Зарегистрирован
-
Посещение
-
Победитель дней
6
1 Подписчик
Посетители профиля
3 012 просмотров профиля
Достижения Werld
Старожил (5/5)
190
Репутация
-
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 нагрузка на процессор периодически подскакивает но в среднем нагрузка от несущественной, до едва заметной)
- 147 ответов
-
- 1
-
-
- adguardhome
- ipset
- (и ещё 1 )
-
Возможно кто-то, как и я, использует 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.
- 147 ответов
-
- 4
-
-
- adguardhome
- ipset
- (и ещё 1 )
-
Так как "ndm/ifstatechanged.d (obsoleted since 4.0, kept only for backward compatibility)", то, думаю, лишь вопрос времени когда скрипты в этом хуке перестанут работать. Теперь предлагается использовать "ndm/iflayerchanged.d (new and primary from 4.0)", соответственно скрипт 010-bypass-table.sh можно перенести в /opt/etc/ndm/iflayerchanged.d внеся минимальные изменения: #!/bin/sh . /opt/etc/bypass.conf [ "$1" == "hook" ] || exit 0 [ "$system_name" == "$VPN_NAME" ] || exit 0 [ ! -z "$(ipset --quiet list bypass)" ] || exit 0 [ "${layer}-${level}" == "link-running" ] || exit 0 if [ -z "$(ip route list table 1001)" ]; then ip route add default dev $system_name table 1001 fi
-
В статье имеется в виду правило, по типу как на изображении Но только адрес назначения нужно указать сеть за VPN-Сервером. В рамках статьи имеется в виду сеть 192.168.22.0/24 Такое правило на домашней сети vpn-клиента, по идее, не нужно, так как там не производится изменение security-level WG-интерфейса. На vpn-сервере это правило необходимо, т.к. после изменения security-level WG-интерфейса на private, траффик из одного private интерфейса (Домашняя сеть) в другой private интерфейс (WG) блокируется. Подробнее о том из каких в какие что блокируется, а что нет, можно почитать https://help.keenetic.com/hc/ru/articles/360001429839-Как-реализован-межсетевой-экран
