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 это подтверждает.

Вроде я про связки MAC-ов ничего не говорил. Да, требуется просто обычное разрешение имен в домашней и рабочей сети. В домашней (соответствующем ей домене) - для hostname-ов устройств, которые они сами сообщают при получении настроек от DHCP сервера, в рабочей (тоже для своего домена) - согласно тому, что сообщают DNS сервера, полученные при поднятии vpn соединения. Указанная строка теоретически должна бы работать, но, как я писал выше, я не обнаружил, что встроенный ndhcps слушает что-то кроме 67 порта после выполнения команды opkg dns-override. Аналогичная строка для рабочего DNS сервера у меня тоже есть в dnsmasq.conf : server=/my_work_domain.local/10.10.1.2#53 но теперь она также не работает. И, кстати, что делать, если завтра "прилетят" при поднятии vpn другие адреса рабочего DNS сервера, руками менять их в dnsmasq.conf?

Думал о чем-то подобном, но (для меня точно) это уж как-то слишком сложно, т.к. потребует, вероятно, написание скрипта для обработки вывода show ip dhcp bindings Более подходящим представляется путь, указанный vasek00 с учетом сказанного Le ecureuil "127.0.0.1:10053 вроде бы, для своих нужд внутренних". Хотя, я и не вижу, чтобы ndhcps занимался чем-то кроме DHCP после команды opkg dns-override root@keenetic:~$ netstat -atunp | grep ndhcp udp 0 0 0.0.0.0:67 0.0.0.0:* 6553/ndhcps udp 0 0 0.0.0.0:67 0.0.0.0:* 6552/ndhcps udp 0 0 0.0.0.0:68 0.0.0.0:* 1130/ndhcpc udp 0 0 0.0.0.0:68 0.0.0.0:* 650/ndhcpc UPD: ТП заверила, что никаких особых зависимостей других служб от ndhcps нет. Советовали только обратить внимание на обнаружение устройств по WiFi (группа команд ip hostpot), но я пока не сообразил, как это может быть связано. Таким образом, самый простой путь, вероятно, запуск/настройка DHCP на dnsmasq с отключением встроенного командой no service dhcp

-Так и сделано - Настроено - Чтобы заработал dnsmasq прошивочный DNS отключается специальной командой в CLI KeeneticOS opkg dns-override. Насколько я понял, эта команда просто убирает прослушку 53-го порта прошивочным ndhcps, чтобы не конфликтовать с dnsmasq. Собственно ndhcps в запущенных процессах остается, т.к. он же продолжает работать в качестве DHCP, поэтому и появилаcь мысль из п.3, но каких-либо файлов настроек для ndhcps я не обнаружил, параметры его запуска весьма скудны (для смены порта ничего нет), и даже, где/как на это повлиять я тоже не знаю. Если это поможет, добавлю подробностей. Началось вот с этого https://habr.com/ru/post/428992/ При этом используется (там же в комментариях) встроенный в KeeneticOS механизм прокси DNS (для DoT/DoH в частности). Спустя небольшое время, я обнаружил, что у меня перестали разрешаться имена в домашней локалке и рабочей (через openvpn) сети. При этом средствами/командами KeeneticOS я вижу, что встроенный ndhcps успешно регистрирует имена хостов в моей домашней сети при общении с ними по DHCP. Теперь пытаюсь решить проблему, как эту инфо сообщить dnsmasq-у. Если я правильно понял, то, следует как-то разруливать DNS запросы через dns-proxy KeeneticOS (есть подозрение, что он работает/настраивается, к сожалению, только для DoT/DoH) к а) прошивочному ndhcps для домена домашней сети (при этом его надо заставить слушать на отличном от 53 порту), б) к NDS серверам, прилетающим через openvpn для домена рабочей сети, в) к DoT/DoH - для всех остальных. Осталось все это правильно настроить, если такое возможно 🙂

Требуется организовать совместную работу встроенного в Keenetic DHCP сервера и внешнего (dnsmasq из OPKG/Entware) сервера DNS. Хочется, чтобы узлы в домашней LAN, автоматически получающие ip адресацию по DHCP, также автоматически регистрировали свой hostname в dnsmasq, по которому (hostname с или без добавления домена) к ним можно обращаться в пределах LAN. Использование dnsmaq вместо ndhcps вызвано необходимостью поддержки ipset. Мне видятся 3 возможных варианта решения: 1) dnsmasq мог бы читать данные из dhcpd.lease, но, судя по всему, этот файл не использует ndhcps; 2) полный отказ от ndhcps и раздача ip адресов средствами dnsmasq, но это может серьезно влиять на другие составляющие NDM, которые используют результаты работы ndhcp; 3) использование DNS прокси для перенаправления запросов на разрешение имен в домашней LAN от dnsmasq к ndhcps (как это настроить?). При этом хочется учесть возможные нюансы с дополнительными DNS серверами, получаемыми через VPN подключение, например, к корпоративной сети и используемыми для разрешения имен в рабочей LAN. ТП Keenetic ожидаемо открестилась от вопроса ("мы не поддерживаем пакеты entware"), сообщив только, что следует рассмотреть вариант 2. Я во всем этом не силен, опасаюсь поломать зависимости ndhcps, поэтому обращаюсь за помощью к сообществу. У кого-то есть опыт успешной настройки такого сценария?

спасибо, т.е. в моем случае все надо делать руками. Возможно, попробую пойти от обратного: сначала установлю asterisk от Keenetic на пустую флэшку, а затем добавлю/донастрою свои пакеты в entware. В общем, подумаю, что для меня будет проще. Еще уточните, пожалуйста, если пойти по вашему рецепту, стартовый скрипт запуска asterisk установится или его надо тоже руками копировать и править?

У меня уже установлен entware и в нем несколько пакетов (mc, openconnect,...). Сейчас хочу добавить asterisk 18 сборки команды Keenetic. Как мне правильно действовать, чтобы сохранить уже установленные пакеты entaware?

Оказалось, что не обязательно. Достаточно добавить стандартными средствами Keenetic Cli или проще через web-интерфейс разрешающее правило (спасибо ТП), цитирую: "на Home сегменте достаточно сделать правило вида источник: локальная сеть, назначение: удалённая сеть, протокол: ip, действие: разрешить" У меня сразу все заработало. В netfilter правило в моем случае выглядит так (добавляется в таблицу по умолчанию filter, цепочку @Bridge0 ) root@keenetic:/opt/etc$ iptables -nL @Bridge0 Chain @Bridge0 (1 references) target prot opt source destination ACCEPT all -- 192.168.100.0/24 172.27.96.0/20

Хочу понять, зачем ставить cron из entaware? Разве crond из состава прошивки/busybox не достаточно для этого?

В этом и сложность, что на систему (приходится) параллельно воздействуют из двух мест - на уровне NDM Shell CLI Keenetic и собственно ОС Linux/bash/...

Заработало. Дело оказалось, действительно в файрволе роутера. После команды no isolate-private доступ к хостам за vpn сервером из моей LAN появился. Мне это не совсем понятно, т.к. в справочнике CLI Keenetic написано, что всем создаваемым новым интерфейсам присваивается public security-level, а трафик из private (Home LAN) в public (tun1) разрешен по умолчанию. Возможно, здесь что-то работает не совсем так, т.к. интерфейс tun1 создан не средствами CLI, а вовсе доп.пакетом из entware и по команде show interface он (tun1) никак не отображается. Попробовал отключить nat-ирование, т.е. убрать правило маскарадинга, все работает и без него. Странно, мои проверки в предыдущем посте показывали его необходимость. Впрочем, tcpdump на интерфейсе tun1 показал, что icmp request уходят с src=ip tun1, т.е. nat-ирование все же работает и без моего доп.правила. В справочнике CLI keenetic нашел команду ip nat vpn которая включает/выключает nat-ирование для vpn клиентов. Во-первых, не ясно, работает ли эта команда для любых vpn-клиентов или только, встроенных в прошивку или для части из них, во-вторых, не указано ее значение по умолчанию, но, похоже, что "включено". Вот так выглядит цепочка POSTROUTING в таблице nat. Проверил, команда no ip nat vpn удаляет из этой цепочки последнее 4-е правило, но доступ из моей LAN к хостам за vpn-сервером сохраняется и в этом случае: # iptables -t nat -nL POSTROUTING --line-numbers Chain POSTROUTING (policy ACCEPT) num target prot opt source destination 1 _NDM_IPSEC_POSTROUTING_NAT all -- 0.0.0.0/0 0.0.0.0/0 2 _NDM_SNAT all -- 0.0.0.0/0 0.0.0.0/0 3 _NDM_MASQ all -- 0.0.0.0/0 0.0.0.0/0 4 MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0 ndmmark match 0x40/0x40 Я не силен в netfilter/iptables, и несколько десятков цепочек/правил в Keenetic понять (пока) не могу, но все равно придется разбираться, как теперь это (файервол) правильно настроить при поднятом туннеле opennconnect, чтобы не попортить настройки безопасности на роутере. Ну и стартовый скрипт для openconnect добавить, конечно.