ValdikSS

WireGuard, везде указано IP-адресами.

# iptables -t nat -vnL ... Chain _NDM_HOTSPOT_DNSREDIR (1 references) ... 1122 70308 REDIRECT udp -- br2 * 0.0.0.0/0 0.0.0.0/0 mark match 0xffffd00 PKTTYPE = unicast udp dpt:53 redir ports 41100 4 208 REDIRECT tcp -- br2 * 0.0.0.0/0 0.0.0.0/0 mark match 0xffffd00 PKTTYPE = unicast tcp dpt:53 redir ports 41100 После удаления этих правил всё работает корректно.

Уже установлено. ! dns-proxy rebind-protect auto filter profile DnsProfile0 description VPN filter profile DnsProfile0 dns53 upstream 8.8.8.8 filter profile DnsProfile0 dns53 upstream 8.8.4.4 filter profile DnsProfile0 intercept no enable filter assign interface profile Bridge2 DnsProfile0 filter engine public !

Как только я удаляю DNS-сервер из стандартного профиля, DNS-резолвинг перестаёт работать в сегменте VPN, независимо от того, что указано в профиле DNS, который я назначаю сегменту VPN. Я уже и совершенно разные адреса указал, и маршруты через VPN-интерфейс до них прописал — ничего. Единственное изменение только в том, что локальный резолвер теперь мне отвечает REFUSED, вместо просто отсутствия ответа. Баг я завёл еще вчера, пока никто не ответил, поэтому написал сюда.

Установил компонент, включил «Публичные DNS-резолверы и настраиваемые профили» в «Режиме фильтрации». Для всех сегментов указан единственный «Системный» профиль DNS, у которого включён транзит. Результат: в стандартном «домашнем» сегменте всё работает корректно, в сегменте VPN — перехват запросов и перенаправление на VPN-резолвер (который стоит последним в списке системного профиля DNS) через кеширующий резолвер на роутере. Создал отдельный профиль DNS со включённым транзитом, указал в нём единственный DNS-резолвер, задал сегменту использовать этот профиль, перезагрузил роутер — запросы в VPN-сегменте всё так же перехватываются. Устройства в VPN-сегменте все незарегистрированные.

У меня нет профилей DNS. Они были раньше (с ними была та же проблема), за них отвечает компонент «Фильтрация контента и блокировка рекламы при помощи облачных сервисов». Сейчас только один, системный. Транзит также опция компонента «Фильтрация контента и блокировка рекламы при помощи облачных сервисов». От его включения и выключения ничего не менялось. Сейчас же, после удаления компонента, опции транзита нет, тем не менее, запросы перехватываются.

Ничего не изменилось.

Не могу понять, каким образом можно отключить перехват (перенаправление) DNS-запросов на внутренний кеширующий резолвер роутера. У меня настроен отдельный сегмент сети, в который я подключаюсь через отдельную сеть Wi-Fi. В сегменте установлена отдельная политика доступа, в которую помещён только WireGuard VPN с перенаправлением всего трафика в туннель. Проблема заключается в том, что все DNS-запросы от клиентов в этом сегменте на любой IP-адрес и порт 53 перенаправляются на внутренний резолвер роутера, на тот IP-адрес, который указан в секции «Профили DNS» раздела «Интернет-фильтр» для интерфейса WireGuard. Если удалить DNS для интерфейса WireGuard из «Профилей DNS», то DNS на клиентах сегмента перестаёт работать вовсе, независимо от адреса DNS-сервера. Иными словами, указав какой-то конкретный DNS в настройках подключения WireGuard (он автоматически дублируется в «Профили DNS»), на клиентских машинах возможно использование только этого DNS, причём трафик до него идёт через внутренний резолвер роутера. Если не указывать никакого DNS в настройках WireGuard, а настроить DNS на компьютерах в сегменте вручную, то DNS-резолв не работает ни на какие адреса. Изначально у меня был установлен компонент «Фильтрация контента и блокировка рекламы при помощи облачных сервисов», но после его удаления ничего не изменилось. Viva (KN-1910) RU, ОС 3.9.8.

Поотлаживал еще. Баг заключается в том, что туннель, после того, как сессия WireGuard «закрылась» (прошло 180 секунд с последнего handshake), не поднимается, когда клиент сегмента начинает отправлять пакеты в туннель. Если отправить какой-либо пакет с самого роутера (например, ping'ом через CLI), либо же с сервера — туннель сразу же поднимается. Некорректно работает какая-то подсистема, возможно, fastvpn.

Добавил, заменив только порт на тот, что указан как listening в настройке клиента. Увы, ничего не поменялось: 187 секунд и серый значок, при том, что какой-то трафик в течение 187 секунд в туннеле ходил (ACK'и и FIN-ACK'и от незакрытых соединений), но он не обновляет счётчик latest handshake.

Вы назначаете туннелю один IPv6-адрес, он используется на самом сетевом интерфейсе. Чтобы выдать адреса компьютерам, нужно дополнительно выделить и смаршрутизировать какую-то подсеть, в случае Keenetic, полагаю, не меньше /64.

Keep-alive установлен в 600. Вы теоретизируете, или действительно разбираетесь, как всё работает в Keenetic? Я сообщаю о проблеме, помочь я себе и сам могу.

Нет, нигде. Да даже если бы был, это бы никак не помешало отправить пакет с роутера на сервер, а они не отправляются, когда туннель становится неактивным.

Keep-alive нужен, чтобы поддерживать NAT-маппинг к серверу, для того, чтобы сервер мог обратиться к клиенту. У меня нет ни NAT'а, ни необходимости сервера обращаться к клиенту. Аналогично настроенный туннель на OpenWrt к тому же серверу работает корректно, даже если по нему не передаются пакеты сутками, без Keep-Alive.

А что там должно быть? Я никаких пакетов не отправляю, соответственно, никаких пакетов и не ходит. Это же stateless-туннель. Но если соединение перешло в состояние неактивного (серая иконка вместо зелёной), то Keenetic и не пытается отправить пакеты на сервер, когда их начинает отправлять какое-либо устройство в сети. Поясню, чтобы развеять возможное недопонимание: у меня для VPN заведен отдельный сегмент со своей сетью Wi-Fi. Wireguard-туннель добавлен в качестве единственного соединения в этом сегменте. В обычном режиме трафик этой сети маршрутизируется через Wireguard. Однако если, например, подключиться к сети Wi-Fi в момент, когда индикатор туннеля серый, то интернета на устройствах нет. Я не понимаю, по какой причине туннель может становиться неактивным: не вижу какой-либо функциональности heartbeat'а у WireGuard (кроме keep-alive), не вижу никаких попыток heartbeat'а в шифрованном трафике на порту WireGuard на сервере. Туннель просто переходит в неактивное состояние без видимых причин и без записей в журнале. Keep-alive установлен в 600 секунд. Падает через 186 секунд.

Да, похоже, действительно какой-то баг. Перезапустил роутер, никак не использовал соединение — упало через 3 минуты (186 секунд latest handshake). В логах при этом абсолютно никаких записей об изменении состояния соединения. Записал видео и отправил в поддержку.

Вам нужен любой протокол VPN, который поддерживает пересылку Ethernet-кадров (L2). Например, OpenVPN в режиме TAP.

Я отключал HWNAT для проверки — его отключение не отключает модуль fastvpn, а ошибки от него. С какими-либо другими соединениями, в т.ч. VPN-соединениями по другим протоколам, проблем не наблюдается. WireGuard — это просто туннель, без какого-либо протокола соединения как такового. Я ожидаю, что он будет постоянно включён и не будет выключаться автоматически, тем более без keep-alive'а.

Наблюдаю похожую проблему на собственном сервере (не Cloudflare Warp). WireGuard настроен в качестве клиента, для отдельного сегмента сети (подключаюсь через отдельную сеть Wi-Fi). В настройках WireGuard-подключения указан фиксированный исходящий порт. Если не задавать keep-alive, то соединение выключается и автоматически не поднимается при подключении устройств к сети Wi-Fi. Приходится заходить в интерфейс и переподключать его вручную. Помогает keep-alive, но и с ним соединение периодически выключается, но само переподнимается. Проблема не в сети: у меня белый IP-адрес без NAT (и фиксированный исходящий порт соединения), keep-alive в этом случае не обязателен. Лог при этом флудится следующими сообщениями без остановки: Jun 5 17:04:51 kernel swnat_mm_realloc: 1135 callbacks suppressed Jun 5 17:04:51 kernel fastvpn: realloc failed Jun 5 17:04:51 kernel Core::Syslog: last message repeated 233 times.

Сам спросил — сам ответил. Вероятно, речь идёт о консольной команде ipv6 static. ipv6 static Описание: Создать правило, разрешающее входящее подключение к заданному порту зарегистрированного устройства домашней сети. Синопсис (config)> ipv6 static ‹protocol› [ ‹interface› ] ‹mac› ‹port› [ through ‹end-port› ] (config)> no ipv6 static [ ‹protocol› [ ‹interface› ] ‹mac› ‹port› [through ‹end-port› ]

Я хочу «открыть порты» для конкретного устройства по IPv6, но не понимаю, как это сделать. Мой провайдер выдаёт IPv6-диапазон через PD, сама связность с устройств работает, сайты пингуются и открываются, всё хорошо. Но как настроить возможность входящих подключений, без отключения firewall'а для IPv6 глобально (no ipv6 firewall), понять не могу. На форуме нашел следующие посты: Но я не могу найти упомянутую функцию по разрешению портов для зарегистрированных устройств. Излазил всё меню, пробовал добавлять правила проброса портов, но там можно ввести только IPv4-адреса, а при выборе зарегистрированного устройства (без ввода адреса) порты IPv6 также недоступны извне. Подскажите, где я могу найти эту функцию, или каким иным образом мне создать разрешающие правила для конкретных портов конкретных устройств по IPv6? У меня Viva (KN-1910) RU, прошивка 3.9.5.