ndm-3868 [NDM-3868] wireguard allow‑ips validator toggling

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

В версии 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 или как то иначе.

Спасибо!

Изменено 23 часа назад пользователем Александр Гольдварг

[Denis P]

1 час назад, Александр Гольдварг сказал:

В версии 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 или как то иначе.

Спасибо!

В чем собственно проблема? Вы уже не первый человек который это упоминает, но толкового объяснения почему и как это должно было работать до внедрения проверки никто предоставить не может

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

Суть ситуации:

У нас есть несколько узлов в сети 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 — это ломание работающей архитектуры, а не её улучшение.

 

 

Изменено 20 часов назад пользователем Александр Гольдварг
Дополнение.

[Denis P]

40 минут назад, Александр Гольдварг сказал:

Суть ситуации:

У нас есть несколько узлов в сети 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 — это ломание работающей архитектуры, а не её улучшение.

 

 

wireguard сам ничего не маршрутизирует (его поведение нельзя назвать классической маршрутизацией), пользуйте статик роуты и будет вам счастье
з.ы ваше сообщение ну уж очень напоминает генерацию с помощью LLM

Изменено 20 часов назад пользователем Denis P

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

Не спешите писать, не разобравшись в вопросе.

Я и не применяю здесь термин "маршрутизация" в его классическом понимании, но иначе как маршрутизацией то, что делает wireguard, не назвать.

А ваше предложение использовать статические маршруты больше похоже на издевательство. Для маршрута нужен интерфейс, и для подсетей 10.0.0.0/8 и 10.0.0.0/24 маршрут будет один - до подсети с более широкой маской.

Если не можете что-нибудь дельное предложить, не пишите.

Спасибо! И надеюсь на понимание.

[Denis P]

21 минуту назад, Александр Гольдварг сказал:

Не спешите писать, не разобравшись в вопросе.

Я и не применяю здесь термин "маршрутизация" в его классическом понимании, но иначе как маршрутизацией то, что делает wireguard, не назвать.

А ваше предложение использовать статические маршруты больше похоже на издевательство. Для маршрута нужен интерфейс, и для подсетей 10.0.0.0/8 и 10.0.0.0/24 маршрут будет один - до подсети с более широкой маской.

Если не можете что-нибудь дельное предложить, не пишите.

Спасибо! И надеюсь на понимание.

речь шла о маршрутах на ваших "клиентах" и использовании отдельных интерфейсов, а не многопирный вариант.

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

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

Слишком много издержек, очевидное различие в поведении, которое описано в документациях технологии и оборудования. Костыль, если позволите.

Но спасибо за предложение.

[Le ecureuil]

Хорошо, валидное замечание. Сделаем чтобы было просто предупреждение в консоли, а дальше пусть все сами думают.

В 4.3.4 и 5.0 будет поправлено.

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

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