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

Ein nettlesar ber om https://203.0.113.10:8443, proxyen tek imot tilkopinga, og tenesta på WireGuard-peeren svarar aldri. DNAT-regelen gjer jobben sin; det er svaret som sviktar. Følg pakken gjennom båe omsetjingane, og den manglande regelen blir tydeleg. Rettinga er ei ekstra NAT-setning i rett hook, ikkje ein ny tunnel.

Følg éin førespurnad frå start til slutt

Førespurnaden kjem inn på den offentlege grensesnittet til proxyen, med den offentlege adressa til klienten som kjelde og proxyadressa som mål. I nat PREROUTING skriv DNAT-regelen om målet til tunneladressa til peeren, 10.90.0.2. Deretter sender rutingsavgjerda pakken ut gjennom wg0, og videresendingsvegen er komplett.

På peeren ber pakken no den opphavlege offentlege kjeldadressa, fordi ingenting har skrive ho om. Tenesta tek imot tilkopinga og sender svaret til sin eigen standard gateway, som er heimerutaren framom peeren. Den rutaren har ingen tilstand for ein flyt han aldri har sett, og han antingen forkastar pakken eller omset han til si eiga offentlege adresse, noko klienten ikkje vil godta.

Asymmetrien er heile problemet: førespurnaden går gjennom proxyen, og svaret prøver å gå direkte. Tilkoplingssporinga til proxyen hjelper berre om svaret kjem tilbake gjennom proxyen, og det kan ikkje kome tilbake dit så lenge kjeldadressa framleis peikar på den opphavlege klienten.

Legg til retur-omsetjinga

Skriv om kjelda til den videresende flyten til tunneladressa til proxyen før han går til peeren. Deretter svarar tenesta til 10.90.0.1, proxyen tek imot det, og tilkoplingssporinga snur båe omsetjingane 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 medvite smal: han passar på den omsette destinasjonen og tunnelgrensesnittet, så han skriv ikkje om uvedkomande trafikk som tilfeldigvis går ut gjennom wg0. Ein brei masquerade-regel ville også skjult klientadressa, men han ville gjort det for kvar flyt og gjort NAT-tabellen vanskelegare å revidere.

Plasser reglane der tunnelen finst

Reglar som viser til tunneladressa eller grensesnittet, må køyre etter at wg-quick har konfigurert det. Grensesnittet blir oppretta før PreUp, men adresser, MTU, DNS og ruter blir brukte etterpå, og PostUp køyrer når alt dette er på plass. Set tillegga i PostUp og slettingane 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

Slettingane må samsvare med tillegga token for token, inkludert multiport- og grensesnittmatch. Ei sletting som avvik med éin match, fjernar ingenting, og neste attoppkopling legg til ein ekstra kopi av regelen. Etter nokre attoppkoplingar inneheld tabellen duplikat som er vanskelege å tilskrive ei konfigurasjonslinje.

Kontroller resultatet med iptables -t nat -S etter ei attoppkopling. Viss same regel blir vist to gonger, passar ikkje PreDown-linja, og oppryddinga feilar stille.

Videresending, filtrering og den andre NAT-en

Aktiver IPv4-videresending permanent, og tillat deretter den videresende flyten i filtertabellen. DNAT skjer før FORWARD-kjeda, så filterregelen passar på den omsette destinasjonen i staden for den offentlege adressa. Viss UFW styrer brannmuren, uttrykk tillatinga som ein ruterregel; ein vanleg vertsregel dekkjer ikkje videresend trafikk.

To andre NAT-lag kan framleis bryte vegen sjølv når proxyreglane er rette. På ei heimetilkopling tilhøyrer den offentlege adressa rutaren, og å opne porten i brannmuren hans er ikkje det same som å opprette ein portvideresendingsoppføring som sender den porten til proxyen. Ein port som ser open ut utanfrå medan ingenting svarar, manglar ofte nettopp den mappinga.

På ein NAT-VPS mappar leverandøren ein offentleg port til ei privat adresse. Mappinga må stemme med porten du annonserer, og eit avvik ser identisk ut med ein broten tunnel. Stadfest mappinga til leverandøren før du endrar WireGuard-konfigurasjonen.

Stadfest returvegen og godta kostnaden

Kople til frå eit nettverk som ikkje er LAN-et til proxyen, og undersøk deretter omsetjingsparet medan tilkopinga er open:

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

conntrack-oppføringa bør vise den opphavlege tuple, den omsette tuple og svarretninga. Viss svaret manglar, sender ikkje peeren gjennom tunnelen, noko som vanlegvis betyr at SNAT-regelen ikkje vart brukt, eller at eigen brannmur på peeren forkasta flyten.

Start på nytt éin gong for å bevise at PostUp brukar reglane på nytt, og stopp deretter tunnelen og stadfest at PreDown fjerna dei. Døde reglar som overlever ei fråkopling, er grunnen til at ei seinare endring oppfører seg uføreseieleg.

Godta til slutt kva SNAT kostar. Tenesta ser kvar førespurnad som kommande frå proxyen, så tilgangsloggar, hastigheitsgrenser per klient og lister over tillatne adresser skil ikkje lenger brukarar. Hairpin-tilfellet treng si eiga kjeldeomsetjing for klientar på LAN-et til proxyen. Viss peeren treng ekte klientadresser, er alternativet ein returrute til klientnettet, som er meir arbeid men bevarer informasjonen.