Port forwarding til en WireGuard-peer bag NAT: DNAT plus SNAT

En browser anmoder om https://203.0.113.10:8443, proxyen accepterer forbindelsen, og tjenesten på WireGuard-peeren svarer aldrig. DNAT-reglen gør sit arbejde; det er svaret, der svigter. Følg pakken gennem begge oversættelser, og den manglende regel bliver tydelig. Rettelsen er en ekstra NAT-sætning i det rigtige hook, ikke en ny tunnel.

Følg én anmodning fra start til slut

Anmodningen ankommer på proxyens offentlige interface med klientens offentlige adresse som kilde og proxyadressen som destination. I nat PREROUTING omskriver DNAT-reglen destinationen til peerens tunneladresse, 10.90.0.2. Ruteafgørelsen sender derefter pakken ud gennem wg0, og videresendelsesvejen er fuldstændig.

På peeren bærer pakken nu den oprindelige offentlige kildeadresse, fordi intet har omskrevet den. Tjenesten accepterer forbindelsen og sender sit svar til sin egen standardgateway, som er hjemmerouteren foran peeren. Den router har ingen tilstand for et flow, den aldrig har set, og den enten dropper pakken eller oversætter den til sin egen offentlige adresse, hvilket klienten ikke vil acceptere.

Asymmetrien er hele problemet: anmodningen går gennem proxyen, og svaret forsøger at gå direkte. Proxyens forbindelsessporing hjælper kun, hvis svaret vender tilbage gennem proxyen, og det kan ikke vende tilbage dertil, så længe kildeadressen stadig peger på den oprindelige klient.

Tilføj retur-oversættelsen

Omskriv kilden for det videresendte flow til proxyens tunneladresse, før det forlader mod peeren. Tjenesten svarer derefter til 10.90.0.1, proxyen modtager det, og forbindelsessporingen vender begge oversættelser, før pakken går tilbage til klienten.

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-reglen er bevidst smal: den matcher den oversatte destination og tunnelinterfacet, så den omskriver ikke uvedkommende trafik, der tilfældigvis forlader gennem wg0. En bred masquerade-regel ville også skjule klientadressen, men den ville gøre det for hvert flow og gøre NAT-tabellen sværere at revidere.

Placer reglerne, hvor tunnelen findes

Regler, der refererer til tunneladressen eller -interfacet, skal køre, efter at wg-quick har konfigureret det. Interfacet oprettes før PreUp, men adresser, MTU, DNS og ruter anvendes bagefter, og PostUp kører, når alt det er på plads. Sæt tilføjelserne i PostUp og sletningerne i 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

Sletningerne skal matche tilføjelserne token for token, inklusive multiport- og interface-match. En sletning, der afviger med ét match, fjerner intet, og den næste genforbindelse tilføjer en ekstra kopi af reglen. Efter nogle genforbindelser indeholder tabellen dubletter, som er svære at henføre til en konfigurationslinje.

Kontroller resultatet med iptables -t nat -S efter en genforbindelse. Hvis den samme regel vises to gange, matcher PreDown-linjen ikke, og oprydningen fejler lydløst.

Videresendelse, filtrering og den anden NAT

Aktivér IPv4-videresendelse permanent, og tillad derefter det videresendte flow i filtertabellen. DNAT sker før FORWARD-kæden, så filterreglen matcher den oversatte destination i stedet for den offentlige adresse. Hvis UFW styrer firewallen, udtryk tilladelsen som en ruteregel; en almindelig værtsregel dækker ikke videresendt trafik.

To andre NAT-lag kan stadig bryde stien, selv når proxyreglerne er korrekte. På en hjemmeforbindelse tilhører den offentlige adresse routeren, og at åbne porten i dens firewall er ikke det samme som at oprette en port-forward-post, der sender den port til proxyen. En port, der ser åben ud udefra, mens intet svarer, mangler ofte netop den mapping.

På en NAT-VPS mapper udbyderen en offentlig port til en privat adresse. Mappingen skal stemme overens med den port, du annoncerer, og en afvigelse ser identisk ud med en brudt tunnel. Bekræft udbyderens mapping, før du ændrer WireGuard-konfigurationen.

Bekræft returvejen, og accepter prisen

Opret forbindelse fra et netværk, der ikke er proxyens LAN, og undersøg derefter oversættelsesparret, mens forbindelsen er åben:

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

conntrack-posten bør vise den oprindelige tuple, den oversatte tuple og svarretningen. Hvis svaret mangler, sender peeren ikke gennem tunnelen, hvilket normalt betyder, at SNAT-reglen ikke blev anvendt, eller at peerens egen firewall droppede flowet.

Genstart én gang for at bevise, at PostUp anvender reglerne igen, og stop derefter tunnelen og bekræft, at PreDown fjernede dem. Døde regler, der overlever en afbrydelse, er grunden til, at en senere ændring opfører sig uforudsigeligt.

Accepter til sidst, hvad SNAT koster. Tjenesten ser hver anmodning som kommende fra proxyen, så adgangslogs, hastighedsgrænser per klient og adresselister over tilladte skelner ikke længere mellem brugere. Hairpin-tilfældet kræver sin egen kildeoversættelse for klienter på proxyens LAN. Hvis peeren har brug for rigtige klientadresser, er alternativet en returrute til klientnetværket, hvilket er mere arbejde, men bevarer informationen.