Jump to content

Werld

Forum Members
  • Posts

    465
  • Joined

  • Last visited

  • Days Won

    6

Werld last won the day on October 6 2022

Werld had the most liked content!

1 Follower

Equipment

  • Keenetic
    KN-1910, KN-1311, KN-1611

Recent Profile Visitors

2806 profile views

Werld's Achievements

Honored Flooder

Honored Flooder (5/5)

190

Reputation

  1. Peer1......Peer2 h1 = h1 ≠ ≠ h2 = h2 ≠ ≠ h3 = h3 ≠ ≠ h4 = h4
  2. 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
  3. Раз 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 должен показать два правила осуществляющие маркировку. Если все на месте, то все должно работать.
  4. Наоборот, 5353 лучше не использовать. Диагностировать поэтапно. Проверяете создана ли таблица маршрутизации. Существует ли ipset. Наполняется ли он. На месте ли правила iptables. Естиь ли в созданной таблице маршрутизации маршрут по умолчанию и т.д.
  5. Не знаю. Мне кажется, это ни к чему. Скриптовая обвязка от этого не изменится.
  6. Ну да.Оба ipset'a должны существовать. Должно быть две таблицы, с разными номерами. В каждой должен быть маршрут по умолчанию через нужный интерфейс. Трафик для попадания в разные таблицы должен маркироваться разными метками.
  7. В вашем случае просто прописываете все домены на один и тот же адрес и порт dnsmasq'a. А уже в конфиге dnsmasq.conf создаете две строки для двух ipset в каждый свои домены: ipset=/ytimg.com/bypass ipset=/intel.com/bypass2
  8. Очевидно как-то не правильно вы пишете дефолтный маршрут в таблицу. Определите корректный шлюз по умолчанию для этого интерфейса и скорректируйте скрипт 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 , чтобы трафик маркировался меткой нужной для этой таблицы:
  9. Ранее в этой теме, автор выкладывал удобный скрипт для отлавливания всех событий в хуках
  10. Переехать в /opt/etc/ndm/iflayerchanged.d Я использую переменные "${layer}-${level}" При включении wg отлавливаю "${layer}-${level}" == "link-running" При отключении руками "${layer}-${level}" == "link-disabled" Все работает. Если пир отваливается, но сам интерфейс на роутере включен, то переменная level переходит в состояние pending и так и висит. Я это не использую, но может вам пригодится
  11. Большое спасибо за готовую к работе обвязку для tpws. Я для себя адаптировал, т.к. не пользуюсь ipv6. Как пишет сам автор, tpws, очевидно, не поможет с quic, а т.к. приложение YT для AndroidTV, например, использует его, то для меня это актуально. У того же автора есть nfqws, которая помогает в том числе и с quic. Но с ней есть некоторые сложности на кинетике, я не стал вникать, решил добить работу через tpws. В общем-то решение простое, можно заблокировать доступ к udp:443, что не позволит устройствам использовать https3/quic и вынудит их откатиться на обычный https. Правилo сделал максимально точным, чтобы не ломать https3 там где мне не нужно Все вроде работает. У меня кн1910, при просмотре очень тяжелого 4k hdr нагрузка на процессор периодически подскакивает но в среднем нагрузка от несущественной, до едва заметной)
  12. Возможно кто-то, как и я, использует 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.
  13. Так как "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
  14. В статье имеется в виду правило, по типу как на изображении Но только адрес назначения нужно указать сеть за 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-Как-реализован-межсетевой-экран
×
×
  • Create New...