Portvideresending til en WireGuard-peer bak NAT: DNAT pluss SNAT

En nettleser ber om https://203.0.113.10:8443, proxyen godtar tilkoblingen, og tjenesten på WireGuard-peeren svarer aldri. DNAT-regelen gjør jobben sin; det er svaret som svikter. Følg pakken gjennom begge oversettelsene, og den manglende regelen blir tydelig. Rettingen er én ekstra NAT-setning i riktig hook, ikke en ny tunnel.

Følg én forespørsel fra start til slutt

Forespørselen kommer inn på proxyens offentlige grensesnitt med klientens offentlige adresse som kilde og proxyadressen som mål. I nat PREROUTING skriver DNAT-regelen om målet til peerens tunneladresse, 10.90.0.2. Deretter sender rutingsbeslutningen pakken ut gjennom wg0, og videresendingsveien er komplett.

På peeren bærer pakken nå den opprinnelige offentlige kildeadressen, fordi ingenting har skrevet den om. Tjenesten godtar tilkoblingen og sender svaret til sin egen standard gateway, som er hjemmeruteren foran peeren. Den ruteren har ingen tilstand for en flyt den aldri har sett, og den enten forkaster pakken eller oversetter den til sin egen offentlige adresse, noe klienten ikke vil godta.

Asymmetrien er hele problemet: forespørselen går gjennom proxyen, og svaret prøver å gå direkte. Proxyens tilkoblingssporing hjelper bare hvis svaret kommer tilbake gjennom proxyen, og det kan ikke komme tilbake dit så lenge kildeadressen fortsatt peker på den opprinnelige klienten.

Legg til retur-oversettelsen

Skriv om kilden til den videresendte flyten til proxyens tunneladresse før den går til peeren. Deretter svarer tjenesten til 10.90.0.1, proxyen mottar det, og tilkoblingssporingen reverserer begge oversettelsene før pakken går tilbake 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-regelen er bevisst smal: den matcher den oversatte destinasjonen og tunnelgrensesnittet, så den skriver ikke om uvedkommende trafikk som tilfeldigvis går ut gjennom wg0. En bred masquerade-regel ville også skjule klientadressen, men den ville gjort det for hver flyt og gjort NAT-tabellen vanskeligere å revidere.

Plasser reglene der tunnelen finnes

Regler som refererer til tunneladressen eller grensesnittet, må kjøre etter at wg-quick har konfigurert det. Grensesnittet opprettes før PreUp, men adresser, MTU, DNS og ruter brukes etterpå, og PostUp kjører når alt dette er på plass. Sett tilleggene i PostUp og slettingene 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

Slettingene må samsvare med tilleggene token for token, inkludert multiport- og grensesnittmatch. En sletting som avviker med én match, fjerner ingenting, og neste gjenoppkobling legger til en ekstra kopi av regelen. Etter noen gjenoppkoblinger inneholder tabellen duplikater som er vanskelige å tilskrive en konfigurasjonslinje.

Kontroller resultatet med iptables -t nat -S etter en gjenoppkobling. Hvis samme regel vises to ganger, matcher ikke PreDown-linjen, og oppryddingen feiler stille.

Videresending, filtrering og den andre NAT-en

Aktiver IPv4-videresending permanent, og tillat deretter den videresendte flyten i filtertabellen. DNAT skjer før FORWARD-kjeden, så filterregelen matcher den oversatte destinasjonen i stedet for den offentlige adressen. Hvis UFW styrer brannmuren, uttrykk tillatelsen som en ruterregel; en vanlig vertsregel dekker ikke videresendt trafikk.

To andre NAT-lag kan fortsatt bryte veien selv når proxyreglene er riktige. På en hjemmetilkobling tilhører den offentlige adressen ruteren, og å åpne porten i brannmuren dens er ikke det samme som å opprette en portvideresendingsoppføring som sender den porten til proxyen. En port som ser åpen ut utenfra mens ingenting svarer, mangler ofte nettopp den mappingen.

På en NAT-VPS mapper leverandøren en offentlig port til en privat adresse. Mappingen må stemme med porten du annonserer, og et avvik ser identisk ut med en brutt tunnel. Bekreft leverandørens mapping før du endrer WireGuard-konfigurasjonen.

Bekreft returveien og godta kostnaden

Koble til fra et nettverk som ikke er proxyens LAN, og undersøk deretter oversettelsesparet mens tilkoblingen er åpen:

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

conntrack-oppføringen bør vise den opprinnelige tuple, den oversatte tuple og svarretningen. Hvis svaret mangler, sender ikke peeren gjennom tunnelen, noe som vanligvis betyr at SNAT-regelen ikke ble brukt, eller at peerens egen brannmur forkastet flyten.

Start på nytt én gang for å bevise at PostUp bruker reglene på nytt, og stopp deretter tunnelen og bekreft at PreDown fjernet dem. Døde regler som overlever en frakobling, er grunnen til at en senere endring oppfører seg uforutsigbart.

Godta til slutt hva SNAT koster. Tjenesten ser hver forespørsel som kommende fra proxyen, så tilgangslogger, hastighetsgrenser per klient og lister over tillatte adresser skiller ikke lenger brukere. Hairpin-tilfellet trenger sin egen kildeoversettelse for klienter på proxyens LAN. Hvis peeren trenger ekte klientadresser, er alternativet en returrute til klientnettet, som er mer arbeid men bevarer informasjonen.