Пренасочване на порт към WireGuard peer зад NAT: DNAT плюс SNAT

Браузър заявява https://203.0.113.10:8443, проксито приема връзката, а услугата на WireGuard peer-а така и не отговаря. Правилото DNAT си върши работата; отговорът е частта, която се проваля. Проследете пакета през двете транслации и липсващото правило става очевидно. Поправката е още един NAT израз в правилния hook, а не нов тунел.

Проследете една заявка от край до край

Заявката пристига на публичния интерфейс на проксито с публичния адрес на клиента като източник и адреса на проксито като дестинация. В nat PREROUTING правилото DNAT пренаписва дестинацията към адреса на тунела на peer-а, 10.90.0.2. След това решението за маршрутизиране изпраща пакета през wg0 и пътят за препращане е завършен.

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

Асиметрията е целият проблем: заявката минава през проксито, а отговорът се опитва да тръгне директно. Проследяването на връзките на проксито помага само ако отговорът се върне през проксито, а той не може да се върне там, докато адресът на източника сочи към оригиналния клиент.

Добавете обратната транслация

Пренапишете източника на препращания поток към адреса на тунела на проксито, преди той да тръгне към peer-а. След това услугата отговаря на 10.90.0.1, проксито го получава и проследяването на връзките обръща двете транслации, преди пакетът да се върне към клиента.

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

Правилото POSTROUTING е умишлено тясно: съвпада с транслатираната дестинация и интерфейса на тунела, така че не пренаписва несвързан трафик, който случайно излиза през wg0. Широко правило masquerade също би скрило адреса на клиента, но би го направило за всеки поток и би направило таблицата NAT по-трудна за одит.

Поставете правилата там, където съществува тунелът

Правила, които реферират адреса или интерфейса на тунела, трябва да се изпълняват, след като wg-quick го е конфигурирал. Интерфейсът се създава преди PreUp, но адресите, MTU, DNS и маршрутите се прилагат след това, а PostUp се изпълнява, след като всичко това е на място. Сложете добавянията в PostUp, а изтриванията в PreDown.

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

Изтриванията трябва да съвпадат с добавянията токен по токен, включително съвпаденията по multiport и интерфейс. Изтриване, което се различава с едно съвпадение, не премахва нищо и следващото повторно свързване добавя второ копие на правилото. След няколко повторни свързвания таблицата съдържа дубликати, които трудно се приписват на ред от конфигурацията.

Проверете резултата с iptables -t nat -S след повторно свързване. Ако същото правило се появи два пъти, редът PreDown не съвпада и почистването се проваля тихо.

Препращане, филтриране и другият NAT

Включете препращането на IPv4 постоянно, след което разрешете препращания поток в таблицата за филтриране. DNAT се случва преди веригата FORWARD, така че правилото за филтър съвпада с транслатираната дестинация, а не с публичния адрес. Ако UFW управлява защитната стена, изразете разрешението като правило за маршрут; обикновено правило за хост не покрива препращан трафик.

Два други слоя NAT все още могат да счупят пътя, дори когато правилата на проксито са правилни. При домашна връзка публичният адрес принадлежи на рутера и отварянето на порта в неговата защитна стена не е същото като създаването на запис за проброс на порт, който изпраща този порт към проксито. Порт, който изглежда отворен отвън, докато нищо не отговаря, често просто няма точно това съпоставяне.

На NAT VPS доставчикът съпоставя публичен порт с частен адрес. Съпоставянето трябва да съвпада с порта, който обявявате, а несъответствието изглежда идентично на счупен тунел. Потвърдете съпоставянето на доставчика, преди да промените конфигурацията на WireGuard.

Проверете обратния път и приемете цената

Свържете се от мрежа, която не е LAN на проксито, след което инспектирайте двойката транслации, докато връзката е отворена:

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

Записът в conntrack трябва да показва оригиналния кортеж, транслатирания кортеж и посоката на отговора. Ако отговорът липсва, peer-ът не изпраща през тунела, което обикновено означава, че правилото SNAT не се е приложило или собствената защитна стена на peer-а е изпуснала потока.

Рестартирайте веднъж, за да докажете, че PostUp прилага отново правилата, след което спрете тунела и потвърдете, че PreDown ги е премахнал. Мъртвите правила, които оцеляват след прекъсване, са причината по-късна промяна да се държи непредвидимо.

Накрая приемете какво струва SNAT. Услугата вижда всяка заявка като идваща от проксито, така че журналите за достъп, ограниченията на скоростта за клиент и списъците с разрешени адреси вече не различават потребителите. Случаят hairpin се нуждае от собствена транслация на източника за клиенти в LAN на проксито. Ако на peer-а са нужни истински адреси на клиентите, алтернативата е обратен маршрут към мрежата на клиента, което е повече работа, но запазва информацията.