Перейти к содержанию

Вопрос

Опубликовано (изменено)

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

Спасибо!

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

Рекомендуемые сообщения

  • 0
Опубликовано
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 или как то иначе.

Спасибо!

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

  • 0
Опубликовано (изменено)

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

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

 

 

Изменено пользователем Александр Гольдварг
Дополнение.
  • 0
Опубликовано (изменено)
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

Изменено пользователем Denis P
  • 0
Опубликовано

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

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

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

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

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

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

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

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

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

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

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

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

  • 0
Опубликовано

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

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

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

  • 0
Опубликовано

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

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

  • 0
Опубликовано

А у меня теперь с  версии 4.3.3 не работает правило Wireguard для выхода в интернет. 

 

Имеем несколько peers, одному пытаюсь назначить AllowedIPs 0.0.0.0/0, и он ругается, что это пересекается с другими пирами. Конечно пересекается, но как мне обозначить через какой peer будет выход в интернет. 

Как то можно откатить это ? Очень нужно плиз. 

  • 0
Опубликовано
21 hours ago, Ivan Semenov said:

А у меня теперь с  версии 4.3.3 не работает правило Wireguard для выхода в интернет. 

 

Имеем несколько peers, одному пытаюсь назначить AllowedIPs 0.0.0.0/0, и он ругается, что это пересекается с другими пирами. Конечно пересекается, но как мне обозначить через какой peer будет выход в интернет. 

Как то можно откатить это ? Очень нужно плиз. 

Откатиться не выйдет, так что придется на dev 5.0 обновляться. Сам обновился - полёт нормальный.

  • 0
Опубликовано
В 18.06.2025 в 19:30, Ivan Semenov сказал:

Как то можно откатить это ? Очень нужно плиз. 

Какая точно марка роутера - 1813 это ошибка 1811 или 1713

На 1811 есть draft 43C2, 43C0, 43B4, 43B1, 43A14, 43A12, 43A3, 43A2, 43A1, 421 и т.д. набор вас устроит почти полный - 28МБ

        <components>acl,base,cloudcontrol,corewireless,ddns,dhcpd,dlna,dns-filter,dns-https,dns-tls,dot1x,eoip,ext,fat,ftp,gre,igmp,ike-client,ip6,ipip,ipsec,l2tp,lang-en,lang-ru,mdns,miniupnpd,monitor,mws,nathelper-esp,nathelper-ftp,nathelper-h323,nathelper-pptp,nathelper-rtsp,ndmp,ndns,netflow,nextdns,ntce,ntfs,ocserver,openconnect,openvpn,opkg,opkg-kmod-fs,opkg-kmod-netfilter,opkg-kmod-netfilter-addons,opkg-kmod-tc,opkg-kmod-usbip,pingcheck,ppe,pppoe,pptp,proxy,sftp,snmp,ssh,sstp,sstp-server,storage,trafficcontrol,transmission,tsmb,udpxy,usb,usblte,usbmodem,usbnet,usbnet-extra,usbqmi,virtual-ip-server,vpnserver,vpnserver-l2tp,webdav,wireguard,wpa-eap,zerotier</components>

 

  • 0
Опубликовано

Что-то в последнее время, что ни апдейт, то больше на саботаж похоже. Я думал, что это баг, а это фича оказывается.

  • 0
Опубликовано
В 18.06.2025 в 19:30, Ivan Semenov сказал:

А у меня теперь с  версии 4.3.3 не работает правило Wireguard для выхода в интернет. 

 

Имеем несколько peers, одному пытаюсь назначить AllowedIPs 0.0.0.0/0, и он ругается, что это пересекается с другими пирами. Конечно пересекается, но как мне обозначить через какой peer будет выход в интернет. 

Как то можно откатить это ? Очень нужно плиз. 

В 4.3.4 можно будет снова.

  • 0
Опубликовано (изменено)
В 21.06.2025 в 15:56, Le ecureuil сказал:

В 4.3.4 можно будет снова.

Скоро выйдет 4.3.4? Вернее, спрошу иначе: выйдет ли она в ближайшие 2 недели? Мне через 2 недели в отпуск уезжать, а вы Wireguard поломали в стабильной версии. 🤬 Он мне в отпуске очень понадобится.

Изменено пользователем Rinaldus
  • 0
Опубликовано (изменено)
В 18.06.2025 в 19:30, Ivan Semenov сказал:

А у меня теперь с  версии 4.3.3 не работает правило Wireguard для выхода в интернет. 

 

Имеем несколько peers, одному пытаюсь назначить AllowedIPs 0.0.0.0/0, и он ругается, что это пересекается с другими пирами. Конечно пересекается, но как мне обозначить через какой peer будет выход в интернет. 

Как то можно откатить это ? Очень нужно плиз. 

В настройках сервера в разрешенных подсетях пропишите адрес_вашего_пира/32 (например, 172.16.82.2/32), а в настройках клиента пропишите 0.0.0.0/0, тогда будет доступ в интернет. Мне только что в соседней теме помогли.

Изменено пользователем Rinaldus
  • 0
Опубликовано
13 hours ago, Rinaldus said:

Скоро выйдет 4.3.4? Вернее, спрошу иначе: выйдет ли она в ближайшие 2 недели?

Ожидаем. Пожалуйста, потерпите!
Спасибо!

  • 0
Опубликовано
В 24.06.2025 в 16:09, Rinaldus сказал:

Мне только что в соседней теме помогли.

Если бы сам роутер не поудалял все прописанные в него подсети после overlap-нутого 0.0.0.0/0, проблемы бы не было. Вернул подсети, трафик пошел.

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.
Примечание: Ваш пост будет проверен модератором, прежде чем станет видимым.

Гость
Ответить на вопрос...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.