Efter en ändrad server-IP pekar SNAT-regeln fortfarande på den gamla

Servern flyttade till en ny adress, klienterna ansluter fortfarande, och ingenting av det de skickar når internet. Den delningen är ledtråden: den lyssnande socketen och portvidarebefordran överlevde flytten, så tunneln kommer upp, medan källöversättningen som tillämpas på vidarebefordrade paket fortfarande anger en adress som värden inte längre äger. Svar på dessa omskrivna paket går till en maskin som inte finns längre.

Anslutning och vidarebefordran misslyckas på olika ställen

Etableringen beror på den slutpunkt klienterna redan känner: den publika adressen, portvidarebefordran framför den och lyssnaren inuti. Den vidarebefordrade trafiken beror på ett andra beslut som fattas efter att paketet kommit in i tunneln, när värden skriver om sin källa så att svaren hittar vägen tillbaka.

En adressändring bryter bara det andra beslutet, och därför läses symptomet som "ansluten men utan internet". Det förklarar också varför de vanliga klientkontrollerna ser friska ut: handskakningen fullbordas, klienten får en adress, och till och med en ping till serverns tunneladress kan svara. Timmar läggs på klienten för ett fel som bor på andra sidan, därför är regeltabellen den första platsen att titta på.

Läs regeln och dess räknare innan du redigerar

Lista översättningsreglerna med räknare och jämför den konfigurerade källan med de adresser värden faktiskt har. En regel som skrivits om till en död adress visar vanligtvis trafik på vägen in, eftersom paketen når den och översätts, och ingenting på vägen tillbaka.

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

Kontrollera tre fält medan du är där: poolen i källmatchningen, utgångsgränssnittet om regeln anger ett, och undantaget som hindrar trafik mellan tunnlar från att skrivas om. Det undantaget är lätt att tappa under en redigering, och tappar man det ser peer-trafik ut att fungera medan svaren tar en märklig väg.

Om räknarna står på noll når paketen aldrig denna regel, och adressen är inte det aktuella problemet. Leta efter en konkurrerande regel tidigare i kedjan, vilket händer när någon lägger till en ersättning i stället för att redigera originalet. Jämför regelnumren med utskriften du antecknade för en minut sedan. Ordning är en del av konfigurationen, inte en kosmetisk detalj.

Ersätt källan, eller sluta ange en

När värden har en stabil adress, ersätt regeln på plats i stället för att lägga till en ny. Ersättning efter regelnummer behåller den ordning som resten av kedjan beror på.

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 tilldelas dynamiskt, ange ingen källa alls och låt kärnan välja den aktuella från utgångsgränssnittet. Den varianten överlever nästa flytt utan redigering, mot att dölja vilken adress som användes.

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

Bekräfta att IPv4-vidarebefordran fortfarande är aktiverad via hanterad konfiguration, och gör sedan regeln varaktig med distributionens egen mekanism. En ändring som bara gjorts i den körande kärnan kommer tillbaka vid nästa omstart, vanligtvis i ett underhållsfönster som ingen kopplar till ändringen.

Två sätt att göra ersättningen fel

Att översätta poolen till serverns tunneladress i stället för dess LAN-adress skickar svaren rakt tillbaka in i tunneln, där de routas mot en klient som aldrig bad om dem. Anslutningen stannar på ett sätt som ser ut som en routningsslinga, eftersom det är en.

Att stapla en andra översättning ovanpå den gamla är det andra felet. Den första matchande regeln vinner, så den inaktuella posten fortsätter hantera paket tills den raderas, och den nya regelns räknare står kvar på noll medan alla skyller på ersättningen. Radera dubbletten innan du lägger till något nytt. Läs sedan listan en gång till och bekräfta att exakt en översättning matchar poolen.

Om tunneln också bär IPv6, upprepa hela genomgången på den andra stacken. En IPv6-standardrutt utan översättning och utan routat prefix misslyckas lika tyst, och det är lätt att glömma eftersom allt ovanför ser identiskt ut.

Inkommande tjänster behöver den motsatta översättningen

En tjänst på en VPN-klient som måste vara nåbar utifrån behöver destinationsöversättning, inte källöversättning: den publika porten skrivs om till klientens tunneladress innan den kommer in. Vidarebefordringsvägen behöver då en uttrycklig regel som tillåter den trafiken.

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

Översätt aldrig porten som bär själva tunneln, för den omskrivningen avbryter anslutningen som håller tjänsten nåbar. Håll tunnelporten helt utanför destinationsreglerna. Verifiera sedan från båda ändar: räknare på den nya regeln, en kort inspelning på tunneleenheten och en begäran till en adress inne i tunneln innan du provar den publika.