Пракід партоў да піра WireGuard за NAT: DNAT плюс SNAT

DNAT дастаўляе запыт, але адказ выходзіць з няправільнага адраса. Дадайце адпаведнае правіла SNAT і размясціце абодва пасля наладкі тунеля.

Браўзер запытвае https://203.0.113.10:8443, проксі прымае злучэнне, а служба на піры WireGuard так і не адказвае. Правіла DNAT робіць сваю справу; памылка ў адказе. Прасачыце пакет праз абодва пераўтварэнні, і адсутнае правіла стане відавочным. Выпраўленне — яшчэ адно выразаванне NAT у патрэбным хуку, а не новы тунель.

Прасачыце адзін запыт ад пачатку да канца

Запыт прыходзіць на публічны інтэрфейс проксі: крыніца — публічны адрас кліента, прызначэнне — адрас проксі. У nat PREROUTING правіла DNAT перазапісвае прызначэнне на адрас тунеля піра, 10.90.0.2. Затым рашэнне маршрутызацыі адпраўляе пакет праз wg0, і шлях перасылкі завершаны.

На піры пакет цяпер нясе зыходны публічны адрас крыніцы, бо нішто яго не перазапісвала. Служба прымае злучэнне і адпраўляе адказ на свой шлюз па змаўчанні — хатні маршрутызатар перад пірам. У гэтага маршрутызатара няма стану для патоку, якога ён ніколі не бачыў, таму ён або скідае пакет, або пераўтварае яго ў свой публічны адрас, а кліент гэтага не прыме.

Асіметрыя — гэта ўся праблема: запыт ідзе праз проксі, а адказ спрабуе ісці напрасткі. Адсочванне злучэнняў проксі дапамагае, толькі калі адказ вяртаецца праз проксі, а ён не можа вярнуцца туды, пакуль адрас крыніцы паказвае на зыходнага кліента.

Дадайце зваротнае пераўтварэнне

Перазапішыце крыніцу перасылаемага патоку на адрас тунеля проксі, перш чым ён пойдзе да піра. Затым служба адказвае на 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 павінен паказваць зыходны картэж, пераўтвораны картэж і напрамак адказу. Калі адказ адсутнічае, пір не адпраўляе праз тунель, што звычайна азначае, што правіла SNAT не прымянілася або ўласны файрвол піра скінуў паток.

Перазагрузіцеся адзін раз, каб даказаць, што PostUp паўторна прымяняе правілы, затым спыніце тунель і пацвердзіце, што PreDown іх выдаліў. Мёртвыя правілы, якія перажываюць адключэнне, — прычына таго, што наступнае змяненне паводзіць сябе непрадказальна.

Нарэшце, прыміце, колькі каштуе SNAT. Служба бачыць кожны запыт як прыйшоўшы ад проксі, таму журналы доступу, абмежаванні хуткасці на кліента і спісы дазволеных адрасоў больш не адрозніваюць карыстальнікаў. Выпадак hairpin патрабуе ўласнага пераўтварэння крыніцы для кліентаў у LAN проксі. Калі піру патрэбны сапраўдныя адрасы кліентаў, альтэрнатыва — зваротны маршрут да сеткі кліента, гэта больш працы, але захоўвае інфармацыю.

Падобныя артыкулы