După o schimbare de IP a serverului, regula SNAT încă o numește pe cea veche

Serverul s-a mutat pe o adresă nouă, clienții se conectează în continuare, și nimic din ce trimit nu ajunge la internet. Această separare este indiciul: socketul de ascultare și redirecționarea portului au supraviețuit mutării, așa că tunelul urcă, în timp ce traducerea sursei aplicată pachetelor redirecționate încă numește o adresă pe care gazda nu o mai deține. Răspunsurile la acele pachete rescrise merg către o mașină care nu mai există.

Conectarea și redirecționarea eșuează în locuri diferite

Stabilirea depinde de punctul final pe care clienții îl știu deja: adresa publică, redirecționarea portului din fața ei și ascultătorul din interior. Traficul redirecționat depinde de o a doua decizie luată după ce pachetul intră în tunel, când gazda își rescrie sursa ca răspunsurile să găsească drumul înapoi.

O schimbare de adresă rupe doar a doua decizie, și de aceea simptomul se citește ca "conectat, dar fără internet". Asta explică și de ce verificările obișnuite din partea clientului par sănătoase: strângerea de mână se încheie, clientul primește o adresă, și chiar un ping către adresa tunelului serverului poate răspunde. Se pierd ore pe client pentru o defecțiune care locuiește în cealaltă parte, de aceea tabelul de reguli este primul loc unde trebuie privit.

Citiți regula și contoarele ei înainte de a edita

Listați regulile de traducere cu contoare și comparați sursa configurată cu adresele pe care gazda le are cu adevărat. O regulă rescrisă către o adresă moartă arată de obicei trafic pe calea de intrare, pentru că pachetele ajung la ea și sunt traduse, și nimic pe calea de întoarcere.

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

Verificați trei câmpuri cât timp sunteți acolo: grupul din potrivirea sursei, interfața de ieșire dacă regula numește una, și excluderea care împiedică rescrierea traficului între tuneluri. Acea excludere se pierde ușor în timpul unei editări, iar pierderea ei face traficul între perechi să pară că funcționează în timp ce răspunsurile lui iau o cale ciudată.

Dacă contoarele stau la zero, pachetele nu ajung niciodată la această regulă și adresa nu este problema actuală. Căutați o regulă concurentă mai sus în lanț, ceea ce se întâmplă când cineva adaugă o înlocuire în loc să editeze originalul. Comparați numerele regulilor cu ieșirea notată acum un minut. Ordinea face parte din configurație, nu este un detaliu cosmetic.

Înlocuiți sursa, sau încetați să mai numiți una

Când gazda are o adresă stabilă, înlocuiți regula la locul ei în loc să adăugați alta. Înlocuirea după numărul regulii păstrează ordinea de care depinde restul lanțului.

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

Când adresa este atribuită dinamic, nu numiți nicio sursă și lăsați nucleul să o aleagă pe cea curentă din interfața de ieșire. Această variantă supraviețuiește următoarei mutări fără editare, cu prețul de a ascunde ce adresă a fost folosită.

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

Confirmați că redirecționarea IPv4 este încă activată prin configurație gestionată, apoi faceți regula permanentă cu mecanismul proprie al distribuției. O modificare făcută doar în nucleul care rulează revine la următoarea repornire, de obicei în timpul unei ferestre de mentenanță pe care nimeni nu o leagă de schimbare.

Două moduri de a greși înlocuirea

Traducerea grupului către adresa tunelului serverului în loc de adresa lui LAN trimite răspunsurile direct înapoi în tunel, unde sunt rutate către un client care nu le-a cerut niciodată. Conexiunea se blochează într-un mod care seamănă cu o buclă de rutare, pentru că este una.

Stivuirea unei a doua traduceri peste cea veche este cealaltă greșeală. Câștigă prima regulă care se potrivește, așa că intrarea învechită continuă să trateze pachete până când este ștearsă, iar contoarele regulii noi rămân la zero în timp ce toți dau vina pe înlocuire. Ștergeți duplicatul înainte de a adăuga ceva nou. Apoi citiți lista încă o dată și confirmați că exact o traducere se potrivește cu grupul.

Dacă tunelul transportă și IPv6, repetați întreaga revizuire pe celălalt stack. O rută implicită IPv6 fără traducere și fără prefix rutat eșuează la fel de silențios, și este ușor de uitat pentru că tot ce este deasupra pare identic.

Serviciile de intrare au nevoie de traducerea opusă

Un serviciu pe un client VPN care trebuie să fie accesibil din exterior are nevoie de traducerea destinației, nu de traducerea sursei: portul public este rescris către adresa tunelului clientului înainte de a intra. Calea de redirecționare are atunci nevoie de o regulă explicită care permite acel trafic.

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

Nu traduceți niciodată portul care transportă tunelul însuși, pentru că acea rescriere întrerupe conexiunea care ține serviciul accesibil. Țineți portul tunelului complet în afara regulilor de destinație. Verificați apoi de la ambele capete: contoare pe regula nouă, o captură scurtă pe dispozitivul tunelului și o cerere către o adresă din interiorul tunelului înainte de a încerca cea publică.