+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

[ошибка?] Wireguard работает с одним интерфейсом и множеством пиров

[ошибка?] Wireguard работает с одним интерфейсом и множеством пиров, RouterOS

leonunix

Guest

17.11.2021 05:06:00

Мой роутер — rb5009 с версией routeros 7.0rc6. Проблема в том, что на одном интерфейсе wg нельзя добавить несколько пиров. Если добавить второго пира, первый перестаёт подключаться, а второй работает. Если удалить второго пира, то и первый не подключается. У кого-нибудь была такая же проблема?

Atrp

Guest

26.01.2022 20:56:00

Как мне использовать allowed-address, если за NAT находятся два пира? Их адреса динамические. На главном роутере только один интерфейс WireGuard. Моя проблема в том, что OSPF работает некорректно при такой конфигурации. Главный роутер: я не могу использовать 0.0.0.0/0 для обоих пиров, потому что "при наличии нескольких пиров на одном интерфейсе WireGuard использует настройку allowed-address, чтобы определить, к какому пиру отправлять пакет". Если я на первом пире ставлю allowed IP 172.16.17.217/28, а на втором — 172.16.17.217/28, пинг работает нормально, но OSPF — нет. Статус OSPF: Init. Если отключить одного пира и для второго использовать allowed IP 0.0.0.0/0, OSPF отлично работает между главным роутером и этим одним пиром. Статус OSPF: Full. Конфигурация пиров: allowed IP 0.0.0.0/0.

Sob Guest	#3 0 28.01.2022 15:55:00 Если вам нужен 0.0.0.0/0, тогда используйте два отдельных интерфейса WG.

anav Guest	#4 0 28.01.2022 18:12:00 Пожалуйста, предоставьте текст, который нужно перевести.

Sob Guest	#5 0 28.01.2022 18:20:00 @anav: Где в твоём примере несколько пиров? Я вижу только маршрутизаторы A и B, значит у каждого будет только один пир — другой маршрутизатор. Не так ли?

anav

Guest

28.01.2022 18:30:00

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

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Вот в чем проблема. Когда на одном интерфейсе несколько пиров, WireGuard использует настройку allowed-addresses, чтобы определить, какому пиру отправлять пакет. Если IP назначения пакета входит в allowed-addresses первого пира, пакет пойдет первому пиару. Если IP входит в allowed-addresses второго пира — второму. У тебя allowed-addresses заданы как 0.0.0.0/0, что совпадает абсолютно со всеми адресами для обоих пиров, но скорее всего он сначала проверит первого пира, и второму пакет никогда не дойдет.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Я не согласен с вышеизложенным, кажется, что он путает несравнимое. ТРАФИК ИСХОДЯЩИЙ ОТ МАРШРУТИЗАТОРА — через туннель. Если трафик исходит от маршрутизатора, настройки пира относятся к адресам, которые маршрутизатор будет искать для совпадения и выбора для отправки в туннель. Поскольку трафик на выходе в 99% случаев относится к локальным подсетям, которые используют туннель, чтобы достучаться до интернета (или других подсетей) с удалённого устройства. Обычно allowed-addresses ставят 0.0.0.0/0, это адреса назначения, с которыми маршрутизатор будет сверяться перед отправкой в туннель. Не вижу, где тут могут возникнуть конфликты или ошибки. Любое другое устройство вне локального маршрутизатора будет иметь свой интерфейс WireGuard и, скорее всего, обратный поток — например, iPhone, заходящий в маршрутизатор через туннель. Поэтому не понимаю, как может быть два разных пира, которые идут в туннель ОТ ОДНОГО УСТРОЙСТВА. Первым делом покажите мне, что такой сценарий вообще возможен! Вторым — объясните, зачем это нужно. Если трафик с любого источника отправляется через туннель и ожидается на другой стороне — он будет разрешён выйти из туннеля и т.д. Нет ни вреда, ни проблемы.

ТРАФИК ВХОДЯЩИЙ НА МАРШРУТИЗАТОР — через туннель. Если трафик приходит на маршрутизатор, настройки пира относятся к адресам, которые фильтруются (а не выбираются), и, соответственно, разрешены к выходу из туннеля и будут обработаны файрволом в WAN или LAN, как положено. Опять же, не вижу никаких конфликтов или ошибок.

Sob

Guest

28.01.2022 19:38:00

Представьте, что у вас сильно цензурированный интернет, где провайдер блокирует доступ к вашим любимым сайтам. Но у вас есть какой-то удалённый сервер — может быть VPS, которую вы купили, или роутер друга, или что угодно. Вы создаёте WG-туннель с вашего роутера к этому серверу и используете его для серфинга в интернете. Всё просто: allowed-address=0.0.0.0/0 с вашей стороны, маршрут по умолчанию через туннель — и прощай, цензура. Но это не надёжно, поэтому вы подключаете ещё один туннель, который тоже не гарантированно работает (потому что провайдер старается вас заблокировать). Но из двух туннелей хотя бы один всегда в строю. Решение — сделать что-то вроде dual WAN, состоящее из WG-туннелей.

И вот в чём проблема. Если использовать один интерфейс WG с двумя пирингами, и у каждого стоит allowed-address=0.0.0.0/0, куда уйдёт пакет на 1.1.1.1? К какому пиру? К одному из них точно, но как выбрать, к какому — непонятно. Сама по себе проблема не критична, ведь можно просто сделать отдельный интерфейс WG под каждый пир. С этим примером всё сразу ясно — это бред. Но если воспринимать WG как обычный интерфейс и забыть про его внутреннюю магию, можно запутаться.

Например, у вас есть удалённый офис с LAN 192.168.88.0/24 и два WAN-канала. Вы хотите сделать туннель до туда, а лучше два — по одному на каждый WAN для резервирования.

/interface wireguard
add name=wg1 ...
/interface wireguard peers
add interface=wg1 allowed-address=10.0.0.2/32,192.168.88.0/24 endpoint-address=<remote1> comment="main"
add interface=wg1 allowed-address=10.0.0.3/32,192.168.88.0/24 endpoint-address=<remote2> comment="backup"
/ip address
add interface=wg1 address=10.0.0.1/24
/ip route
add dst-address=192.168.88.0/24 gateway=10.0.0.2 distance=1 check-gateway=ping
add dst-address=192.168.88.0/24 gateway=10.0.0.3 distance=2

На первый взгляд всё отлично, правда? Так бы и сделали с Ethernet — валидная и рабочая конфигурация. Два шлюза (10.0.0.2 и 10.0.0.3) и стандартная схема failover для маршрутов. Если всё нормально, трафик к 192.168.88.0/24 идёт через 10.0.0.2, а при падении основного туннеля (когда 10.0.0.2 недоступен) переключается на 10.0.0.3.

Но это не сработает, потому что если WG-интерфейс получает пакет для 192.168.88.100, куда он его отправит — на первый или второй пир? Он не знает, ведь не понимает вообще ничего про маршрутизацию, это совсем другой уровень. Для него есть два пира, и 192.168.88.100 может пойти к любому из них, так что он выбирает наугад (на самом деле, конечно, нет).

anav Guest	#8 0 28.01.2022 20:00:00 Понял, тогда в этом случае единственное действительно работающее решение — использовать совсем другой интерфейс wireguard.

Sob

Guest

28.01.2022 20:06:00

Кроме какого-то безумного хака (*), да. (*) Ты можешь начать без 192.168.88.0/24 в allowed-address, использовать netwatch для мониторинга 10.0.0.2 и 10.0.0.3 и добавлять 192.168.88.0/24 к right peer на этом основании. Но на самом деле так делать не стоит.

Atrp

Guest

#10

29.01.2022 12:53:00

Сначала хочу понять: почему OSPF не работает, если в главном маршрутизаторе allowed-address не 0.0.0.0/0? Пинг с главного маршрутизатора и клиента проходит отлично, я могу включить EOIP-туннель поверх Wireguard-туннеля — и он тоже работает хорошо, значит сеть в порядке. Но OSPF — в состоянии init. Я не хочу использовать два интерфейса Wireguard, потому что для каждого требуется по два порта. И это, честно говоря, не идеальное решение.

Sob

Guest

#11

29.01.2022 18:42:00

Я недостаточно хорошо знаю OSPF, может быть, у него есть какие-то дополнительные требования. Но просто так в WG нельзя назначать одинаковый allowed-address более чем одному пиру. Подумай сам: есть peer1 с allowed-address=0.0.0.0/0 и peer2 с allowed-address=0.0.0.0/0. А теперь ты хочешь отправить пакет на 1.2.3.4 — как ты решишь, к какому пиру его направить? Никак.

AKSN74 Guest	#12 0 02.12.2022 03:53:00 Я знаю, что эта тема уже старая, но позвольте объяснить. Согласно описанию OSPF на Википедии, OSPF использует multicast-пакеты для согласования друг с другом и проверки, жив ли сосед. Для этого он применяет IP-адрес 224.0.0.5 в качестве multicast при работе в типах сетей broadcast и ptp (иногда может использовать 224.0.0.6 в broadcast-сетях). Исходя из этого, вам нужно добавить 224.0.0.0/24 в allowed address в настройках WireGuard на стороне пира, чтобы WireGuard не блокировал OSPF-соединение. Кстати, также нужно прописать LAN-подсети с другой стороны, иначе WireGuard может заблокировать пакеты, адресованные этим подсетям. Но даже при этом, если у вас несколько площадок, которые нужно связать через OSPF, придется создать отдельный интерфейс WireGuard для каждой. То есть для каждой площадки – свой интерфейс. Потому что все соседи OSPF используют 224.0.0.5 для обмена, и возникнет та же ситуация, о которой говорил пункт #6. Зато на одном интерфейсе WireGuard вы можете объединить одну площадку и несколько клиентов (ПК, смартфон и т.п.).

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры