Portvidarebefordran till en WireGuard-peer bakom NAT: DNAT plus SNAT

En webbläsare begär https://203.0.113.10:8443, proxyn accepterar anslutningen och tjänsten på WireGuard-peeren svarar aldrig. DNAT-regeln gör sitt jobb; det är svaret som misslyckas. Följ paketet genom båda översättningarna och den saknade regeln blir uppenbar. Rättelsen är en extra NAT-sats i rätt hook, inte en ny tunnel.

Följ en begäran från början till slut

Begäran kommer in på proxyns offentliga gränssnitt med klientens offentliga adress som källa och proxyns adress som mål. I nat PREROUTING skriver DNAT-regeln om målet till peerens tunneladress, 10.90.0.2. Sedan skickar routningsbeslutet ut paketet via wg0 och vidarebefordringsvägen är komplett.

På peeren bär paketet nu den ursprungliga offentliga källadressen, eftersom ingenting har skrivit om den. Tjänsten accepterar anslutningen och skickar svaret till sin egen standardgateway, som är hemroutern framför peeren. Den routern har ingen tillstånd för ett flöde den aldrig sett och antingen kastar paketet eller översätter det till sin egen offentliga adress, vilket klienten inte accepterar.

Asymmetrin är hela problemet: begäran går genom proxyn och svaret försöker gå direkt. Proxyns anslutningsspårning hjälper bara om svaret kommer tillbaka genom proxyn, och det kan inte komma tillbaka dit så länge källadressen fortfarande pekar på den ursprungliga klienten.

Lägg till returöversättningen

Skriv om källan för det vidarebefordrade flödet till proxyns tunneladress innan det lämnar mot peeren. Tjänsten svarar då till 10.90.0.1, proxyn tar emot det och anslutningsspårningen vänder båda översättningarna innan paketet går tillbaka till 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-regeln är medvetet smal: den matchar den översatta destinationen och tunnelgränssnittet, så den skriver inte om orelaterad trafik som råkar gå ut via wg0. En bred masquerade-regel skulle också dölja klientadressen, men den skulle göra det för varje flöde och göra NAT-tabellen svårare att granska.

Placera reglerna där tunneln finns

Regler som refererar till tunneladressen eller gränssnittet måste köra efter att wg-quick har konfigurerat det. Gränssnittet skapas före PreUp, men adresser, MTU, DNS och rutter tillämpas efteråt, och PostUp körs när allt detta är på plats. Lägg tilläggen i PostUp och borttagningarna 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

Borttagningarna måste matcha tilläggen token för token, inklusive multiport- och gränssnittsmatchningarna. En borttagning som skiljer sig i en matchning tar bort ingenting, och nästa återanslutning lägger till en andra kopia av regeln. Efter några återanslutningar innehåller tabellen dubbletter som är svåra att tillskriva en konfigurationsrad.

Kontrollera resultatet med iptables -t nat -S efter en återanslutning. Om samma regel visas två gånger matchar inte PreDown-raden och städningen misslyckas tyst.

Vidarebefordran, filtrering och den andra NAT:en

Aktivera IPv4-vidarebefordran permanent och tillåt sedan det vidarebefordrade flödet i filtertabellen. DNAT sker före FORWARD-kedjan, så filterregeln matchar den översatta destinationen i stället för den offentliga adressen. Om UFW hanterar brandväggen, uttryck tillåtelsen som en routningsregel; en vanlig värdregel täcker inte vidarebefordrad trafik.

Två andra NAT-lager kan fortfarande bryta vägen även när proxyreglerna är korrekta. På en hemanslutning ägs den offentliga adressen av routern, och att öppna porten i dess brandvägg är inte samma sak som att skapa en portvidarebefordran som skickar den porten till proxyn. En port som ser öppen ut utifrån medan ingenting svarar saknar ofta just den mappningen.

På en NAT-VPS mappar leverantören en offentlig port till en privat adress. Mappningen måste stämma med porten du annonserar, och en avvikelse ser identisk ut med en bruten tunnel. Bekräfta leverantörens mappning innan du ändrar WireGuard-konfigurationen.

Verifiera returvägen och acceptera kostnaden

Anslut från ett nätverk som inte är proxyns LAN och undersök sedan översättningsparet medan anslutningen är öppen:

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

conntrack-posten bör visa den ursprungliga tupeln, den översatta tupeln och svarsriktningen. Om svaret saknas skickar inte peeren genom tunneln, vilket vanligtvis betyder att SNAT-regeln inte tillämpades eller att peerens egen brandvägg kastade flödet.

Starta om en gång för att bevisa att PostUp tillämpar reglerna igen, stoppa sedan tunneln och bekräfta att PreDown tog bort dem. Döda regler som överlever en frånkoppling är anledningen till att en senare ändring beter sig oförutsägbart.

Acceptera slutligen vad SNAT kostar. Tjänsten ser varje begäran som kommande från proxyn, så åtkomstloggar, hastighetsgränser per klient och listor över tillåtna adresser skiljer inte längre användare. Hairpin-fallet behöver sin egen källöversättning för klienter på proxyns LAN. Om peeren behöver riktiga klientadresser är alternativet en returrutt till klientnätverket, vilket är mer arbete men bevarar informationen.