LINUX.ORG.RU
ФорумAdmin

wireguard клиент за NAT не видит ответов сервера

 , , ,


0

1

К своему стыду или счастью не имел дел с WG до текущего момента.

Вынудили тут установить на роутер для входа в частную сеть.
Вроде настроил и запустил. Вроде запустилось, но клиенты не могут поднять Handshake. Причём заметил, что не могут это сделать только те клиенты, у которых интернет через NAT.

В tcpdump на роутере с NAT это видно вот так:

00:16:53.196597 ppp0  Out IP <client.router.ip>.60641 > <wg.server.ip>.51820: UDP, length 148
00:16:53.371485 ppp0  In  IP <wg.server.ip>.33438 > <client.router.ip>.60641: UDP, length 92

со стороны клиента за NAT конечно же второй пакет (ответ от сервера WG) не приходит. Я вижу в этом логику NAT роутера такую, что это какой-то неизвестный ему пакет, такого в conntrack нету и он его отбрасывает, ибо не знает кому в сети его передать. Это и логично.
А как это должно работать? Есть какой-то WG conntrack helper? Не нашёл, да и как он узнает какие порты то пробрасывать? Можно как-то «заморозить» порт ответа от сервера? А как? тоже не нашёл...

Пример конфига сервера:
[Interface]
Address = 192.168.9.1/24
ListenPort = 51820
PrivateKey = 8KuFf8BE9dV/WQwCOTYhEjaNGIQKI5/VdyEfYyg4WHY=

[Peer]
# Client 1
PublicKey = e0p9r6uAZBMeZgEHT2YiflkPCQEdV3c4UhlfC/jahjo=
AllowedIPs = 192.168.9.2/32
PersistentKeepAlive = 25

Пример конфига клиента:
[Interface]
PrivateKey = sNF9d5uBmiK6HuuTA0enPf0nNZ6hKsBAvm/ug0LT7UU=
Address = 192.168.9.2/32, fd00:9::2/128
ListenPort = 51820
DNS = 192.168.9.1

[Peer]
PublicKey = LZEOHsadmY84S+dlL3sdRybTg64BJdnyAnfK/ld7slE=
# PresharedKey not used
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = router.org:51820
PersistentKeepAlive = 25

Ответ на: комментарий от anonymous

Вообще то на тот.

(надеюсь он на раутере, или где там у него nat, включил какую нибудь шнягу по типу UPnP или подобное)

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

На сервере в AllowedIPS должны быть сети за клиентом, если не включен нат на интерфейс на клиенте. Это неочевидный косяк, просто надо знать. Исходя из этого насыпать маршрутов. Если это исключено, гляди в сторону mtu.

Anoxemian ★★★★★
()

Я вижу в этом логику NAT роутера такую, что это какой-то неизвестный ему пакет, такого в conntrack нету и он его отбрасывает, ибо не знает кому в сети его передать. Это и логично.

Бывают роутеры, которые при отправке udp пакета запоминают только локальный адрес, то есть делают полноценный открытый входящий udp-порт (но временный, если долго нет пакетов - забывает его) после того как из локалки что-то куда-то отправили. Зачем так делают - я не знаю, может быть для удешевления, а может быть как раз для подобных случаев, ведь есть и другие случаи, когда на начатую udp-сессию приходят сообщения с разных айпи-адресов. На этом поведении основано например «udp hole punching» - способ соединить по udp двух юзеров за разными натами.

Как должен работать wg и дейсвительно ли он должен отвечать с другого порта - я не знаю, никогда им не пользовался.

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

PersistentKeepAlive

На сервере не нужно. Также не нужно на клиентах не за NAT. Так как им нет необходимости поддерживать соединение включенным, оно без проблем поднимется при необходимости.

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

Да вроде как раз на тот, только с другого.
ушло с 60641 и пришло на 60641. Тут как раз всё хорошо.
Опять же про трансляцию... Её ещё не произошло, это трафик между 2мя белыми IP: сервера и роутера(клиента) скажем так...

Вот только далее роутер клиента не транслирует трафик клиенту через NAT.

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

В попытках найти истину, пробовал уже разные варианты. Да не нужно. Но и не должно повлиять, ну будет он слать keep alive, это же не блокер в данной ситуации так-то...

Spider55
() автор топика
Последнее исправление: Spider55 (всего исправлений: 1)
Ответ на: комментарий от mx__

Это мы своей головой с остатками знаний понимаем. Но в документации на wg сказано, что клиент имеет право находится за nat без каких-то танцев с бубном. Ну или я не нашёл

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

Но только UPnP к нату, а уж темболее conntrack имеет последнее отношение.
Это отдельный протокол с отдельным набором функционала, один из которых открытие порта в NAT, и то костылями через firewall скрипты.
В общем целом он не нужен для корректной работы NAT как такового.
А уж WireGuard про него ничего не знает. Беглый поиск по репозиториям (искал по windows кожу ибо он максимально все в себе) ничего не дал...

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

Да как бы я же вижу трафик на роутере клиента. Он почему то не проходит сквозь НАТ к клиенту...
Не пойму куда смотреть... в conntrack нет «соединения» того самого которое должно было быть «пробито» udp «соединением».

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

В общем целом он не нужен для корректной работы NAT как такового.

нуда, только у вас не ТСП а UDP, и это не ответ запрос если что. Читайте про NAT и UDP тогда.

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

Методом проб и ошибок я попробовал коннект с другими WG серверами. И там всё работает от этого же клиента за NAT. Поменялся только WG сервер.
И вот очевидное различие которое объединяет их всех и отделяет от меня.
Это то, что они ОТВЕЧАЮТ с того же порта на который я соединяюсь.

Вот пример (ps. какой-то публичный WG сервер, его адрес я нашёл в гугле, так что скрывать нечего):

18:29:21.976907 eth0   In  IP 192.168.60.100.55779 > 46.149.74.165.39786: UDP, length 148
18:29:21.976938 ppp0  Out IP <client_router_ip>.55779 > 46.149.74.165.39786: UDP, length 148
18:29:22.058286 ppp0  In  IP 46.149.74.165.39786 > <client_router_ip>.55779: UDP, length 92
18:29:22.058315 eth0   Out IP 46.149.74.165.39786 > 192.168.60.100.55779: UDP, length 92

Следующий конфиг клиента был использован
[Interface]
PrivateKey = [cut]
Address = 10.161.167.10/24
DNS = 1.1.1.1

[Peer]
PublicKey = [cut]
PresharedKey = [cut]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = 46.149.74.165:39786
PersistentKeepalive = 25

как видно выше, то при handshake сервер отвечал пакетами с того же порт = 39786, куда клиент коннектился. Для NAT клиента это полностью законная ситуация и всё работает как ожидалось. (без всяких UPnP и прочей ерунды)

В моём же случае почему то меняется исходящий порт... Как так не понимаю пока... в этом wg сложно что-то напутать, он устанавливается парой команд сам...

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