Videreformidle port til en WireGuard-peer bak NAT: DNAT og SNAT

Nettleseren ber om https://203.0.113.10:8443, proxyen tar imot forbindelsen, og tjenesten på WireGuard-peeren svarer aldri. DNAT-regelen gjør det den skal; det er svaret som ikke kommer frem. Følg pakken gjennom begge oversettelsene, så blir den manglende regelen åpenbar. Løsningen er en ekstra NAT-linje i riktig hook, ikke en ny tunnel.

Følg én forespørsel hele veien

Forespørselen ankommer proxyens offentlige grensesnitt, med klientens offentlige adresse som kilde og proxyens adresse som mål. I nat PREROUTING omskriver DNAT-regelen målet til peerens tunneladresse, 10.90.0.2. Rutingavgjørelsen sender deretter pakken ut via wg0, og videresendingsveien er komplett.

På peeren bærer pakken nå den opprinnelige offentlige kildeadressen, siden ingenting har skrevet den om. Tjenesten tar imot forbindelsen og sender svaret til sin egen standard gateway, som er hjemmeruteren foran peeren. Den ruteren har ingen tilstand for en strøm den aldri har sett, og den slipper pakken eller oversetter den til sin egen offentlige adresse, noe klienten ikke godtar.

Hele problemet er asymmetrien: forespørselen går via proxyen, mens svaret forsøker å gå direkte. Proxyens forbindelsessporing hjelper bare dersom svaret kommer tilbake via proxyen, og det kan ikke komme tilbake dit så lenge kildeadressen fortsatt peker på den opprinnelige klienten.

Legg til returoversettelsen

Skriv om kilden for den videresendte strømmen til proxyens tunneladresse før den forlater mot peeren. Tjenesten svarer da til 10.90.0.1, proxyen mottar det, og forbindelsessporingen 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 med vilje smal: den treffer den oversatte destinasjonen og tunnelgrensesnittet, og skriver derfor ikke om uvedkommende trafikk som tilfeldigvis går ut via wg0. En vid masquerade-regel ville også skjult klientadressen, men den ville gjort det for hver strøm og gjort NAT-tabellen vanskeligere å revidere.

Sett reglene der tunnelen finnes

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

Fjerningene må samsvare med tilleggene token for token, også multiport- og grensesnitttreff. En fjerning som avviker med ett treff, fjerner ingenting, og neste gjenoppkobling legger til en ekstra kopi av regelen. Etter noen gjenoppkoblinger inneholder tabellen duplikater som er vanskelige å knytte til en konfigurasjonslinje.

Sjekk resultatet med iptables -t nat -S etter en gjenoppkobling. Hvis samme regel dukker opp to ganger, treffer ikke PreDown-linjen, og oppryddingen feiler stille.

Videresending, filtrering og den andre NAT-en

Slå på IPv4-videresending permanent, og tillat deretter den videresendte strømmen i filtertabellen. DNAT skjer før FORWARD-kjeden, så filterregelen treffer den oversatte destinasjonen og ikke 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 ødelegge veien selv om proxyreglene er riktige. På en hjemmeforbindelse eier ruteren den offentlige adressen, og å åpne porten i brannmuren er ikke det samme som å lage en portvideresending som sender porten til proxyen. En port som ser åpen ut utenfra mens ingenting svarer, mangler ofte nettopp den koblingen.

På en NAT-VPS kobler leverandøren en offentlig port til en privat adresse. Koblingen må stemme med porten du kunngjør, og avvik ser likt ut som en ødelagt tunnel. Bekreft leverandørens kobling før du endrer WireGuard-oppsettet.

Kontroller returveien og godta kostnaden

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

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

conntrack-oppføringen skal vise den opprinnelige tuple, den oversatte tuple og retningen på svaret. Mangler svaret, sender ikke peeren gjennom tunnelen, noe som vanligvis betyr at SNAT-regelen ikke ble brukt, eller at peerens egen brannmur kastet strømmen.

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

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