LINUX.ORG.RU
ФорумAdmin

WIreGuard связь между с клиентами за натом.

 , , ,


3

2

Ну во общем решил и я прикоснутся к прекрасному VPN будущего и столкнулся с такой проблемой: Собственно конфигурация сети такая есть 3 пира (ABC) и один из них B имеет реальный айпи адрес, не за натом с открытым портом, а сам пир с реальным айпи. Вот пиры А,C сидят за натом. ну и сеть впн 10.9.9.0/24 и у всех клиентов прописано Alloweded IP 10.9.9.0/24. Ну вот по чему то пир B который с реальным айпи видит всех участников, а сами клиенты только участника B, т.е. между ними связи нет (Last handshake never) . и в логах у клиента A такое сообщение.

No valid endpoint has been configured or discovered for peer2.

И кстати сам условный сервер с реальным айпи он видит все энд поинты обоих клиентов. отображает их айпм и с каких UDP портов с ними общаются. Собственно, где это хваленый nat-traversal, где прямая связь между пирами, сеть же видит их айпишники открытые порты UDP.



Последнее исправление: Loafter (всего исправлений: 1)

Ну все нормально. Peer B у тебя видимо в роли «сервера», к нему подключаются peer A и C.

Поэтому он и может с ними общаться.

Поднимай для пира C и A отдельную сеть. Тогда в рамках маршрутизации все будет работать.

kostik87 ★★★★★
()
Ответ на: комментарий от Loafter

Могут.

1) На машине B net.ipv4.ip_forward должен быть включен
2) На машинах А и С - или нужно будет прописать «route» через B для сетки 10.9.9.0/24 или же дать B ip адрес 10.9.9.1 и wg-quick сам пропишет нужный роут (на А и С)

beka
()
Последнее исправление: beka (всего исправлений: 2)
Ответ на: комментарий от Loafter

В Wireguard пакеты отправленные в канал шифруются открытым ключом пира получателя.

В рамках одного адресного пространства пакеты адресуются посредством адреса физического устройства (мак адреса).

При подключении пира A к пиру B устанавливается соединение только между ними. И они знают ключи друг друга.

Пир B не знает ключ пира C.

kostik87 ★★★★★
()
Ответ на: комментарий от Radjah

Тут собственно главный вопрос является ли WireGuard mesh сетью? По сути мне то нужно решить простую задачу, что бы клиенты были в одном адресном пространстве за NAT и что бы пакеты ходили от клиента до клиента минуя основной сервер.

Loafter
() автор топика

У меня именно такая конфигурация и всё працюе. ¯_(ツ)_/¯

Т.е. один пир «сервер» с публичным IP и фиксированным портом, к которому коннектятся все остальные. При этом все могут общаться друг с другом.

beastie ★★★★★
()
Ответ на: комментарий от beka

Могут.

WireGuard на B между пирами бридж делает что ли? А если да, то .ip_forward тут при чём? А то, если не бридж, одной сети там быть не может на двух разных пирах.

AS ★★★★★
()

В качестве альтернативы могу предложить рассмотреть tailscale. Он также построен с использованием WireGuard протокола. Хосты за натом соединяются либо через upnp, либо через координационные сервера. Есть возможность пускать весь трафик через одну ноду (что обычно и делают с помощью VPN). В качестве координационного сервера можно использовать self-hosted вариант с открытым исходным кодом (headscale).

unikum ★★★★★
()
Ответ на: комментарий от unikum

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

Loafter
() автор топика
Ответ на: комментарий от beastie

Получается на «сервере» прописываем всех пиров? А на «клиентах» только пир «сервера», других «клиентов» не прописываем?

PS. В Archwiki требуется дописать раздел для данного сценария использования Wireguard.

NyXzOr ★★★
()
Ответ на: комментарий от Radjah

В wireguard понятие сервера очень условное. Целевую конфигурацию вполне можно реализовать. С учетом NAT скорее всего придется использовать пир с реальным адресом в качестве координатора, но после установления соединения должно работать.

Топикстартеру рекомендую все же запостить все конфиги, предварительно убедившись, что все ключи и ip там совпадают (а перед публикацией – затерты).

Siborgium ★★★★★
()
12 августа 2022 г.
Ответ на: комментарий от Xi_Jingping

Требовать у провайдера ipv6 надо, а не костыли через сервера городить.

Ты ещё найди такого провайдера. Я вот на днях обнаружил, что у Ростелекома есть IPv6 и с виду даже рабочий. Попробовал. Через него ходит 2/3 трафика. Но одно но. Сам провайдер блокирует любые входящие соединения. Т.е. можно только TCP использовать для связи с внешним миром. Входящие подключения не работают даже если на маршрутизаторе разрешить прямо. С UDP тоже засада. Через соединение Wireguard как бы даже пинги ходят, но ничего, естественно, не работает из-за блокировки входящих пакетов на клиенте. И да, это не мои кривые руки, т.к. аналогичное соединение между серверами с полноценным IPv6 работает на ура.

Так что ни Wireguard, ни звонить, ни торренты покачать через IPv6 не получится.

Feonis ★★★
()
Последнее исправление: Feonis (всего исправлений: 2)
Ответ на: комментарий от Xi_Jingping

Пните вашего провайдера в лицо за такую херню.

Меня просто удивило, что это хоть как-то работает. 5 лет назад я обзванивал всех доступных провайдеров в городе миллионнике. Но ни один не предоставлял IPv6 официально. Был один, но он не подключал в том месте, где я жил. Ну а тут я оформил заявку, мол криво работает IPv6. Позвонил «специалист» и сказал, что мы рекомендуем его отключать… Ну и что с таких взять? Если бы была достойная альтернатива, то понятное дело, сменил бы. Но у других и этого может не быть.

Feonis ★★★
()