Efter en ændret server-IP peger SNAT-reglen stadig på den gamle

Serveren er flyttet til en ny adresse, klienterne opretter stadig forbindelse, og intet af det, de sender, når internettet. Den opdeling er sporet: den lyttende socket og portvideresendelsen overlevede flytningen, så tunnelen kommer op, mens kildeoversættelsen, der anvendes på videresendte pakker stadig peger på en adresse, som værten ikke længere ejer. Svar på disse omskrevne pakker går til en maskine, der ikke findes mere.

Forbindelse og videresendelse fejler forskellige steder

Etablering afhænger af det endepunkt, klienterne allerede kender: den offentlige adresse, portvideresendelsen foran den og lytteren indeni. Den videresendte trafik afhænger af en anden beslutning, der træffes, efter pakken er kommet ind i tunnelen, hvor værten omskriver sin kilde, så svarene kan finde vej tilbage.

En adresseændring bryder kun den anden beslutning, og derfor læses symptomet som "forbundet, men intet internet". Det forklarer også, hvorfor de sædvanlige klientkontroller ser sunde ud: håndtrykket fuldføres, klienten får en adresse, og en ping til serverens tunneladresse kan endda svare. Der bruges timer på klienten på en fejl, der bor på den anden side, og derfor er regeltabellen det første sted at kigge.

Læs reglen og dens tællere, før du redigerer

List oversættelsesreglerne med tællere, og sammenlign den konfigurerede kilde med de adresser, værten faktisk har. En regel, der er omskrevet til en død adresse, viser normalt trafik på vej ind, fordi pakkerne når den og oversættes, og intet på vej tilbage.

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

Kontrollér tre felter, mens du er der: puljen i kildematchningen, udgangsinterfacet hvis reglen angiver et, og den udelukkelse, der forhindrer tunnel-til-tunnel-trafik i at blive omskrevet. Den udelukkelse er let at miste under en redigering, og mister man den, ser peer-trafik ud til at virke, mens dens svar tager en mærkelig vej.

Hvis tællerne står på nul, når pakkerne aldrig denne regel, og adressen er ikke det aktuelle problem. Se efter en konkurrerende regel tidligere i kæden, hvilket sker, når nogen tilføjer en erstatning i stedet for at redigere originalen. Sammenlign reglenumrene med det output, du noterede for et minut siden. Rækkefølge er en del af konfigurationen, ikke en kosmetisk detalje.

Erstat kilden, eller hold op med at angive en

Når værten har en stabil adresse, skal du erstatte reglen på stedet i stedet for at tilføje en ny. Erstatning efter reglenummer bevarer den rækkefølge, som resten af kæden afhænger af.

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

Når adressen tildeles dynamisk, angiv slet ingen kilde, og lad kernen vælge den aktuelle fra udgangsinterfacet. Den variant overlever den næste flytning uden redigering, mod at skjule, hvilken adresse der blev brugt.

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

Bekræft, at IPv4-videresendelse stadig er aktiveret via administreret konfiguration, og gør derefter reglen varig med distributionens egen mekanisme. En ændring, der kun er lavet i den kørende kerne, vender tilbage ved næste genstart, normalt i et vedligeholdelsesvindue, som ingen forbinder med ændringen.

To måder at gøre erstatningen forkert

At oversætte puljen til serverens tunneladresse i stedet for dens LAN-adresse sender svarene direkte tilbage i tunnelen, hvor de dirigeres mod en klient, der aldrig bad om dem. Forbindelsen går i stå på en måde, der ligner en routingløkke, fordi det er en.

At stable en anden oversættelse oven på den gamle er den anden fejl. Den første matchende regel vinder, så den forældede post bliver ved med at håndtere pakker, indtil den slettes, og den nye regels tællere forbliver på nul, mens alle skyder skylden på erstatningen. Slet dubletten, før du tilføjer noget nyt. Læs derefter listen en gang til, og bekræft, at præcis én oversættelse matcher puljen.

Hvis tunnelen også bærer IPv6, skal du gentage hele gennemgangen på den anden stak. En IPv6-standardrute uden oversættelse og uden dirigeret præfiks fejler lige så lydløst, og det er let at glemme, fordi alt ovenover ser identisk ud.

Indgående tjenester har brug for den modsatte oversættelse

En tjeneste på en VPN-klient, som skal kunne nås udefra, har brug for destinationsoversættelse, ikke kildeoversættelse: den offentlige port omskrives til klientens tunneladresse, før den kommer ind. Videresendelsesvejen kræver så en udtrykkelig regel, der tillader den trafik.

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

Oversæt aldrig den port, der bærer selve tunnelen, for den omskrivning afbryder den forbindelse, der holder tjenesten tilgængelig. Hold tunnelporten helt ude af destinationsreglerne. Kontrollér derefter fra begge ender: tællere på den nye regel, en kort optagelse på tunneleenheden og en anmodning til en adresse inde i tunnelen, før du prøver den offentlige.