Na een IP-wijziging van de server noemt de SNAT-regel nog de oude

De server is naar een nieuw adres verhuisd, clients verbinden nog steeds, en niets van wat ze sturen bereikt het internet. Die splitsing is de aanwijzing: de luisterende socket en de port forwarding overleefden de verhuizing, dus de tunnel komt op, terwijl de brontranslatie die op doorgestuurde pakketten wordt toegepast nog steeds een adres noemt dat de host niet meer bezit. Antwoorden op die herschreven pakketten gaan naar een machine die er niet meer is.

Verbinden en doorsturen falen op verschillende plaatsen

Het opzetten hangt af van het eindpunt dat clients al kennen: het openbare adres, de port forwarding ervoor en de listener binnenin. Doorgestuurd verkeer hangt af van een tweede beslissing die wordt genomen nadat het pakket de tunnel binnenkomt, wanneer de host zijn bron herschrijft zodat antwoorden de weg terug vinden.

Een adreswijziging breekt alleen de tweede beslissing, en daarom leest het symptoom als "verbonden maar geen internet". Dat verklaart ook waarom de gebruikelijke controles aan de clientkant gezond lijken: de handshake rondt af, de client krijgt een adres, en zelfs een ping naar het tunneladres van de server kan antwoorden. Er gaan uren naar de client voor een fout die aan de andere kant zit, daarom is de regeltabel de eerste plek om te kijken.

Lees de regel en zijn tellers voordat je bewerkt

Lijst de vertaalregels met tellers op en vergelijk de geconfigureerde bron met de adressen die de host werkelijk heeft. Een regel die naar een dood adres is herschreven, toont meestal verkeer op de heenweg, omdat pakketten hem bereiken en vertaald worden, en niets op de terugweg.

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

Controleer drie velden terwijl je er bent: de pool in de bronmatch, de uitgaande interface als de regel er een noemt, en de uitsluiting die verkeer tussen tunnels tegen herschrijven beschermt. Die uitsluiting raak je bij een bewerking makkelijk kwijt, en het verlies ervan laat verkeer tussen peers werken terwijl de antwoorden een vreemde weg nemen.

Staan de tellers op nul, dan bereiken pakketten deze regel nooit en is het adres niet het huidige probleem. Zoek een concurrerende regel eerder in de keten, wat gebeurt wanneer iemand een vervanging toevoegt in plaats van het origineel te bewerken. Vergelijk de regelnummers met de uitvoer die je een minuut geleden noteerde. Volgorde is deel van de configuratie, geen cosmetisch detail.

Vervang de bron, of noem er geen meer

Heeft de host een stabiel adres, vervang de regel dan ter plaatse in plaats van er een toe te voegen. Vervangen op regelnummer behoudt de volgorde waarvan de rest van de keten afhangt.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

Wordt het adres dynamisch toegewezen, noem dan helemaal geen bron en laat de kernel het huidige uit de uitgaande interface kiezen. Die variant overleeft de volgende verhuizing zonder bewerking, tegen de prijs dat verborgen blijft welk adres is gebruikt.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

Bevestig dat IPv4-doorsturen nog via beheerde configuratie is ingeschakeld, en maak de regel daarna duurzaam met het eigen mechanisme van de distributie. Een wijziging die alleen in de draaiende kernel is gedaan, komt terug bij de volgende herstart, meestal in een onderhoudsvenster dat niemand aan de wijziging koppelt.

Twee manieren om de vervanging verkeerd te doen

De pool naar het tunneladres van de server vertalen in plaats van naar zijn LAN-adres stuurt antwoorden meteen terug de tunnel in, waar ze naar een client worden gerouteerd die er nooit om vroeg. De verbinding blijft hangen op een manier die op een routeringslus lijkt, omdat het er een is.

Een tweede translatie bovenop de oude stapelen is de andere fout. De eerste passende regel wint, dus de verouderde vermelding blijft pakketten afhandelen tot hij wordt verwijderd, en de tellers van de nieuwe regel blijven op nul terwijl iedereen de vervanging de schuld geeft. Verwijder het duplicaat voordat je iets nieuws toevoegt. Lees daarna de lijst nog eens en bevestig dat precies één translatie bij de pool past.

Draagt de tunnel ook IPv6, herhaal dan de hele controle op de andere stack. Een IPv6-standaardroute zonder translatie en zonder gerouteerde prefix faalt net zo stil, en het is makkelijk te vergeten omdat alles erboven identiek lijkt.

Inkomende diensten hebben de omgekeerde translatie nodig

Een dienst op een VPN-client die van buitenaf bereikbaar moet zijn, heeft doeldestinatie-translatie nodig, geen brontranslatie: de openbare poort wordt naar het tunneladres van de client herschreven voordat hij binnenkomt. Het doorstuurpad heeft dan een uitdrukkelijke regel nodig die dat verkeer toestaat.

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

Vertaal nooit de poort die de tunnel zelf draagt, want die herschrijving onderbreekt de verbinding die de dienst bereikbaar houdt. Houd de tunnelpoort volledig buiten de bestemmingsregels. Controleer daarna vanaf beide kanten: tellers op de nieuwe regel, een korte opname op het tunnelapparaat en één verzoek naar een adres binnen de tunnel voordat je de openbare probeert.