ale_xb

Конечно (только не забудьте на имена своих интерфейсов, номера таблиц маршрутизации, маркировки сменить): #!/bin/sh [ "$1" == "hook" ] || exit 0 [ "$layer" == "link" ] || exit 0 [ "$id" == "Wireguard2" ] || exit 0 IF_NAME=nwg2 IF_GW4=$(ip -4 addr show "$IF_NAME" | grep -Po "(?<=inet ).*(?=/)") case ${layer}-${level} in link-disabled|link-pending) logger "====WG2 DOWN=====" ip -4 rule del fwmark 0xd1000 lookup 1001 priority 1778 2>/dev/null ip -4 route flush table 1001 ;; link-running) logger "====WG2 UP=====" ip -4 route add table 1001 default via "$IF_GW4" dev "$IF_NAME" 2>/dev/null ip -4 route show table main |grep -Ev ^default |while read ROUTE; do ip -4 route add table 1001 $ROUTE 2>/dev/null ip -4 rule add fwmark 0xd1000 lookup 1001 priority 1778 2>/dev/null ip -4 route flush cache ;; esac exit 0

Спасибо. Работает! Я на всякий случай добавил оба условия и потерю коннекта и "административный down": case ${layer}-${level} in link-disabled|link-pending) .... link-running) .....

Обновился (старенькая черная Ultra II, ветка delta) с версии 3.9.8 до версии 4.1.7 (4.01.C.7.0-1) и что-то сломалось. Настраивал выборочный роутинг с помощью ipset и dnsmaq-full по описанию из соседней (теперь удаленной/закрытой) на этом форуме ветке. Похоже, перестал отрабатывать хук-скрипт /opt/etc/ndm/ifstatechanged.d/10m-redirect4.sh из-за того, что статусы используемого мною vpn интерфейса теперь как-то иначе отображаются. Добавил в скрипт строку для их логирования logger ${id}-${change}-${connected}-${link}-${up} и вот, что получил в результате при ручном включении/выключении в веб-интерфейсе настроенного и рабочего Wireguard туннеля: Aug 8 21:26:02 keenetic ndm: Core::System::StartupConfig: configuration saved. Aug 8 21:26:02 keenetic ndm: Network::Interface::Base: "Wireguard2": "wireguard" changed "link" layer state "pending" to "running". Aug 8 21:26:02 keenetic root: Wireguard2-link-no-up-up Aug 8 21:26:02 keenetic root: Wireguard2-link-no-up-up Aug 8 21:26:24 keenetic ndm: Network::Interface::Base: "Wireguard2": "base" changed "conf" layer state "running" to "disabled". Aug 8 21:26:24 keenetic ndm: Network::Interface::Base: "Wireguard2": interface is down. Aug 8 21:26:24 keenetic ndm: Core::System::StartupConfig: saving (http/rci). Aug 8 21:26:24 keenetic root: Wireguard2-link-no-up-up Aug 8 21:26:24 keenetic kernel: wireguard: Wireguard2: peer "xxxxxxxxxxxxxxxxxxx" (15) (xxx.xxx.xxx.xxx:xxxx) destroyed Aug 8 21:26:24 keenetic root: Wireguard2-link-no-up-up Aug 8 21:26:28 keenetic ndm: Core::System::StartupConfig: configuration saved. Не понятны 2 вещи: 1. При поднятии/отключении интерфейса Wireguard (state "pending" to "running" и state "running" to "disabled") получаю почему-то по ДВЕ записи в лог, а не одну. 2. При поднятии и отключении интерфейса обе записи одинаковые (Wireguard2-link-no-up-up), поэтому скрипт не работает, дополнительная таблица 1001 для роутинга не создается. Что мне следует проверить/исправить?

Судя по тому, что уже тестируется 4.0 alfa 5 и в списке есть, например, интересующая меня Ultra II надежда есть!

Я все же не понимаю, как конфиг из web-интерфейса (для ipv4 только) будет соседствовать с конфигом из скрипта. Указанный в скрипте Endpoint engage.cloudflareclient.com разрешается в два адреса ipv6 и ipv4. Скрипт в качестве конфига, судя по всему, прописывает ipv6 адрес. Как только скрипт срабатывает, туннель wireguard в web-интерфейсе сразу падает. Что я неправильно делаю/понимаю?

Нашел, спасибо. wireguard-tools Да, в курсе, буду апгрейдиться до 3.8 в delta, как выйдет.

у меня 3.7.4. Насколько понимаю, в этом случае надо просто добавить для ipv6 адрес на интерфейс Wireguard и AllowedIPs в параметры туннеля. Адрес добавляется без проблем, а AllowedIPs нет: (config)> interface Wireguard2 wireguard peer <Public Key peer-а> allow-ips ::/0 Command::Base error[7405602]: address: argument parse error. Похоже, в CLI также не предусмотрена установка параметров Wireguard для ipv6, как и в веб интерфейсе. Также я не могу воспользоваться и вашим способом, т.к. у меня нет команды wg. Из какого пакета Entware она? Я верно понял вот это ваше замечание "нужен ещё аналог ipv6 nat Wireguard2, например для warp. А иначе с br0 идут реальные ipv6 адреса", что пакеты из туннеля приходят с ipv6 warp-а, а не пира в этом туннеле Wireguard...? Почему так, ведь у вас же прописан маскарадинг ip6t POSTROUTING -t nat -o nwg2 -j MASQUERADE ?

Если я, наконец, правильно Вас понял, то update-dhcp в действительности поддерживается, просто его забыли описать. Ок, спасибо еще раз. Попробую все это доделать на днях. И все же последнее не правильнее ли это делать через файл hosts? можете, что сказать по полному отказу от ndhcps в пользу dnsmasq, что я мог неверно сделать и мне следует проверить?

Все же я что-то не понимаю. Вы же сами выше писали, что действие update-dhcp не поддерживается в neighbour.d, т.е. скрипт update-dhcp.sh не будет никогда запускаться.

Ура, работает. Спасибо! Уточнения: 1. Требуется установить парсер json: opkg install jq 2. В строке curl ..... вместо server, вероятно, следует писать address, т.е. curl -s http://localhost:79/rci/show/ip/dhcp/bindings 2>/dev/null | jq -r '.lease[] | "address=/" + .name + ".lan/" + .ip' > $dns_dhcp_tmp директива server говорит, что для данного домена за разрешением имен следует обращаться на хост с указанным IP, т.е. DNS запрос для, например, xyz.lan будет форвардиться dnsmasq-ом в этом случае на ip этого самого xyz.lan и, разумеется, оставаться безответным - NXDOMAIN. address - тоже не правильный вариант, т.к. для, например, abc.xyz.lan будет возвращен тот же ip, что и для xyz.lan (см.Доп.вопросы ниже), но этого в моем случае достаточно. 3. Пока не доделал/разобрался, как, куда и на какое действие правильно повесить этот скрипт. Займусь попозже. Доп.вопросы: А в чем разница, если аналогичным скриптом обновлять файл hosts ? Что лучше/правильнее - hosts или конфиг dnsmasq-а? Вроде, hosts приоритетнее конфига dnsmasq и не будет неоднозначности для abc.xyz.lan/xyz.lan. не понятно, почему аналогичного результата я не смог добиться, когда пытался в качестве DHCP использовать dnsmasq вместо прошивочного ndhcps. Может, это более правильный и простой путь без доп.скриптов, и мне надо только разобраться с конфигом dnsmaq в части его DHCP функционала, аналогичного команде ip dhcp pool _WEBADMIN update-dns у прошивочного ndhcps Keenetic?

Вы об update-dhcp, которого нет? Или я вас не понял. Устроит любой вариант. Мне бы простыми словами понятную инструкцию...

пробовал отключить прошивочный ndhcps и раздавать всё необходимое по DHCP средствами dnsmasq. Работает, но нужного результата я все равно не смог добиться, не хватает понимания настроек dnsmasq.conf, вероятно. Может, кто помочь конкретным конфигом? Повторю задачу (конкретные значения указаны в качестве примера): 1. Раздать ip адреса в домашней локалке, например, 192.168.0.2-200. 2. Сообщить вместе с ip адресом: правильную маску /24 шлюз по умолчанию 192.168.0.1 DNS сервер 192.168.0.1 При необходимости он уже сам либо отвечает за домен домашней локалки, либо форвардит запрос upstream-у по DoT/DoH, либо DNS серверу в рабочей сети, полученному при поднятии соответствующего VPN, с привязкой к ее (рабочей сети) домену work-domain. адрес(а)/имена NTP сервера(ов) - это просто для удобства pool.ntp.org имя домена домашней локалки home 3. Получить в процессе назначения IP адреса запросившему его хосту в домашней локалке его (хоста) hostname и зарегистрировать данное имя, как hostname.home в базе лиз dnsmasq и/или файле hosts В итоге должны успешно разрешаться имена вида xyz и xyz.home для хостов в домашней локалке и abc.work-domain для хостов в рабочей сети, ну и, разумеется, ya.ru, google.ru и все остальное. Проблема у меня именно с п.3 😒

С этим разобрался. DNS серверы на работе нормально "прилетают" при поднятии VPN и разрешают имена для рабочего домена. Cрабатывала защита от получения ответов апстримов с частными ip адресами из-за вот этой строки в dnsmasq.conf stop-dns-rebind Пришлось добавить рабочий домен в исключения: rebind-domain-ok=/onion/home/my_work_domain.local/

Заметил еще одну странность dnsmasq. Это не совсем по теме, но близко. При попытке ping storage.xxx.local хоста в рабочем домене с хоста в домашней LAN вижу в tcpdump на роутере, что идет попытка разрешения указанного имени. При этом запрос корректно форвардится на рабочие DNS серверы и приходит правильный ответ. Здесь все ожидаемо, вопросов не вызывает. Но, если послать явный запрос на разрешение этого же имени командой nslookup storage.xxx.local, сначала формируется запрос с добавлением доменного суффикса home моей домашней LAN и только затем следует правильный запрос без оного. Если в конце запрашиваемого в nslookup FDQN поставить точку, то суффикс home ожидаемо не добавляется. Я ожидал, что суффикс будет добавляться только для запросов по имени без какого-либо суффикса вовсе. Можно ли добиться именного такого поведения dnsmasq, что надо поправить в его конфиге?

Помогите разобраться, пожалуйста. Тему прочитал, но так и не понял, куда обращается сам роутер при разрешении имен с DoT/DoH. У меня настроен DoT на 3 сервера 1.0.0.1, 8.8.4.4, 9.9.9.9 на странице "Интернет-фильтр", других DNS в web-интерфейсе нигде не указано. Также "прилетают" DNS серверы из двух VPN подключений PPTP 192.168.0.1 (домен не важен и не указан, т.к. здесь инфо от этого DNS не использую) и OpenVPN 10.10.1.2, 10.10.1.5 (домен xxx.local). Адрес роутера в домашней локалке (домен home) 192.168.100.1. В web интерфейсе в настройках подключения к провайдеру установлена галочка "Игнорировать DNS". Вместо встроенного ndhcps (53-й его порт "погашен" командой opkg dns-override) настроен dnsmasq. Конфиг вот: теперь, что я вижу и вопросы: 1. В web-интерфейсе (Системный монитор/Подробнее о соединении): DNS-серверы 2a02:2168:208:1::1 2a02:2168:208:2::1 Судя, по всему, "Игнорировать DNS" не распространяется на ipv6. Его можно (проверил), отключить командой interface ISP no ipv6 name-servers auto, но, будет ли в таком случае работать bootstrap для DoT/DoH (не выяснил). И, похоже, нет смысла ставить галочку "Игнорировать DNS", верно? 2. По команде show ip name-server я вижу все серверы - из п.1, и "прилетевшие по VPN", правда провайдерские ipv6 DNS почему-то указаны, как "Client-eth3", хотя ISP у меня GigabitEthernet1, как у большинства: 3. По команде show dns-proxy я вижу три моих DoT сервера. Здесь почему-то статические записи для устройств в домашней локалке указаны дважды - с и без домена home. Это нормально? Кстати, попутный вопрос: Как назначаются ранки этим серверам? По выводу так и не ясно. Максимальный - и не у самого быстрого, и не у самого медленного. 4. Проверяю на роутере, как идет разрешение имен. Почему, если не указать явно DNS сервер, обращение идет к серверу, "прилетевшему" по VPN PPTP ? Возможно, потому, что у меня для этого сервера не указан домен (см.самое начало поста)? Можно ли ему указать абстрактный фейковый в настройках dnsmasq, чтобы к нему не было обращений? Но в любом случае, получается, сам роутер для разрешения имен не использует dns-proxy и соответственно DoT/DoH. Разве так должно быть? И подскажите, пожалуйста, как проверить/убедиться с хоста в локалке, что для него разрешение имен идет через dns-proxy, т.е. своего рода трассировку запросов/ответов DNS. Собственно dns-proxy работает. tcpdump на lo интерфейсе показывает обращения на порты 40500-40502, да и вывод статистики в п.3 это подтверждает.