Александр Гольдварг

Премного благодарен!

То есть вы предлагаете переделать работающую архитектуру сети, просто потому что теперь есть валидатор подсетей, который дублирует и режет функционал wireguard? Слишком много издержек, очевидное различие в поведении, которое описано в документациях технологии и оборудования. Костыль, если позволите. Но спасибо за предложение.

Не спешите писать, не разобравшись в вопросе. Я и не применяю здесь термин "маршрутизация" в его классическом понимании, но иначе как маршрутизацией то, что делает wireguard, не назвать. А ваше предложение использовать статические маршруты больше похоже на издевательство. Для маршрута нужен интерфейс, и для подсетей 10.0.0.0/8 и 10.0.0.0/24 маршрут будет один - до подсети с более широкой маской. Если не можете что-нибудь дельное предложить, не пишите. Спасибо! И надеюсь на понимание.

Суть ситуации: У нас есть несколько узлов в сети WireGuard, и мы хотим настроить маршрутизацию так, чтобы одни узлы могли служить шлюзами для других, даже если они находятся в одной и той же подсети. 🔹 Пример: Есть большая подсеть 10.0.0.0/8. В ней — сервер server1.domain с IP 10.0.0.1. Конфигурация пира для него: [Peer] # name: server1.domain PublicKey = ... AllowedIPs = 10.0.0.1/32 AllowedIPs = 10.0.0.0/8 Есть другая, вложенная подсеть 10.0.0.0/24, и сервер server2.domain с IP 10.0.0.100. Конфигурация пира: [Peer] # name: server2.domain PublicKey = ... AllowedIPs = 10.0.0.100/32 AllowedIPs = 10.0.0.0/24 Такую конфигурацию WireGuard спокойно обрабатывает и маршрутизирует, несмотря на пересекающиеся сети. 🔹 Что это даёт? Допустим, есть узел node1, у которого настроены оба пира — server1.domain и server2.domain. Также есть узлы node2, node3 и т.д., у которых есть только соединение с server2.domain, и им выданы адреса в подсети 10.0.0.0/24. Теперь, если node1 захочет достучаться до node2, WireGuard сам правильно выберет маршрут — через server2.domain, потому что маршрут 10.0.0.0/24 более специфичный, чем 10.0.0.0/8. 🔹 Зачем это нужно? Не все узлы в сети должны быть напрямую связаны между собой. Некоторые пиры работают как маршрутизаторы (relay) для других. Это позволяет строить гибкие и изолированные топологии. Именно для таких сценариев и создавался WireGuard — без принудительных ограничений и валидаторов. Если кратко: WireGuard сам умеет разруливать пересекающиеся AllowedIPs по принципу «наиболее специфичный маршрут». Принудительный запрет таких конфигураций в Keenetic 4.3.3 — это ломание работающей архитектуры, а не её улучшение.

В версии 4.3.3 был добавлен валидатор подсетей для wireguard для изоляции пиров, что обычно делается поднятием другого интерфейса. Фактически был обрезан функционал туннеля. Enhanced the allow‑ips validator to prevent overlapping networks across multiple WireGuard peers, ensuring proper routing and peer isolation. [NDM-3868] Если возможно, откатите, пожалуйста, изменения. Или хотя бы дайте возможность валидатор отключить через cli или как то иначе. Спасибо!