alblks

у меня-то как раз никаких, благо, роутер тянет awg-go, который я могу как собрать сам, так и, при желании, трезво оценивая риски, даже скачать готовый бинарник. а вот советовать васянские сборки нубам я бы не стал. моветон-c... (впрочем, ту тему уже и так снесли. туда и дорога.)

я бы, если честно, не доверял бинарнику "от Васяна", крутящемуся на уровне ядра. исходников на гитхабе нет никаких, только скрипт для скачивания.

При нажатии кнопки "Удалить" в диалоге редактирования правила - удаляется не оно, а первое в списке. Что, в случае если редактировалось не первое правило - очевидно, не то, чего ожидает пользователь. После редактирования или даже включения/выключения любого правила - напрочь отваливается IPv6 форвардинг. То есть, скажем, с роутера пинги к внешним v6 хостам идут, но из локальной сети за ним - уже нет. Лечится перезапуском провайдерского соединения (ну, или перезагрузкой роутера). Видимо, отваливается что-то либо в файрволле, либо в маршрутизации, а перезапуск соединения восстанавливает настройки.

Что такое "не предусмотрен"? УМВР (y меня всё работает). В конфиге сервера IPv6 адрес указан? IPv6 адреса есть `AllowedIPs` на обоих пирах? Форвардинг IPv6 на сервере разрешён и пропускается файрволлом (хотя это уже вопрос не к Амнезии, а к настройкам сервера)?

А это нормально, что SMTP сервер почти сразу после синхронизации с аплинком убегает на секунду? $ ndmc -c show ntp status status: elapsed: 115 server: 1.ru.pool.ntp.org accurate: yes synchronized: yes ndsstime: no usertime: no а на хосте в локальной сети наблюдаем такое: $ ntpq -pn remote refid st t when poll reach delay offset jitter ================================================================================================== 192.168.1.1 .LOCL. 1 u 21 64 1 0.4774 -379.110 0.0000 0.ru.pool.ntp.org .POOL. 16 p - 256 0 0.0000 0.0000 0.0001 +88.87.70.219 89.109.251.21 2 u 10 64 1 34.7324 3.1905 0.0937 *91.201.254.110 194.190.168.1 2 u 10 64 1 23.1783 0.5868 0.2345 +45.141.102.99 89.109.251.24 2 u 10 64 1 21.0504 0.5622 0.4517 +188.130.255.102 91.235.144.128 2 u 10 64 1 105.1255 -11.9497 0.0673 $ntpdig 192.168.1.1 2025-08-14 15:24:45.682336 (+0500) -1.151976 +/- 0.125250 192.168.1.1 s1 no-leap Обратите внимание на первую строчку. Это чо за дикий оффсет через пару минут после, типа, синхронизации? Кому такая служба времени нужна?

Подтверждаю. Если потом руками выдать "interface PPPoE0 dyndns update", апдейт проходит. Вообще работа службы DynDNS с IPv6 довольно странная. Она, скажем, считает, что сервер, к которому обращается, обязан иметь IPv4-адрес, и если его нет, отваливается с ошибкой. Хотя существуют сервисы, у которых URL для обновлений IPv6 просто не имеет адреса IPv4 в принципе.

interface Wireguard0 down interface Wireguard0 up в ndmc-консоли. Но раз упомянут ifconfig, то речь, видимо, про командную строку Entware - тогда, соответственно ndmc -c interface Wireguard0 down ndmc -c interface Wireguard0 up (вместо Wireguard0 подставить имя интерфейса, если оно отличается)

Наткнулся на некую странность (прошивка последняя стабильная 4.2.6.1). После установления соединения с OpenVPN-сервером NDM зачем-то удаляет дефолтный IPv6-маршрут (причём уже после отработки хука из /opt/etc/ndm/openvpn-route-up.d , то есть помешать этому с помощью какого-то Opkg-скрипта невозможно): [I] Mar 1 21:31:29 root: openvpn-route-up ndm_opkg_id=OpenVPN0 ndm_opkg_argc=0 ... [I] Mar 1 21:31:30 ndm: Network::Interface::Ip6: "OpenVPN0": removing default route via OpenVPN0. С IPv4-маршрутом при этом ничего такого не происходит. НО! Если в конфиг openvpn добавить "route-delay" секунды в 3, то всё в порядке, дефолтный маршрут никуда не девается: (config)> show ipv6 route table 10 sort destination ascending route6: destination: ::/0 gateway: :: interface: OpenVPN0 metric: 1024 flags: U rejecting: no proto: boot floating: no static: no Собственно, вопрос — я очень сомневаюсь, что это поведение так задумано. Но если таки да, может быть, есть смысл это где-нибудь описать?