Nakon promjene IP adrese servera, SNAT pravilo još navodi staru

Server se preselio na novu adresu, klijenti se još povezuju, a ništa od onoga što pošalju ne stiže do interneta. Ta podjela je trag: socket koji sluša i prosljeđivanje porta preživjeli su selidbu, pa se tunel podigne, dok prevođenje izvora primijenjeno na proslijeđene pakete još navodi adresu koju host više ne posjeduje. Odgovori na te prepisane pakete idu prema mašini koje više nema.

Povezivanje i prosljeđivanje padaju na različitim mjestima

Uspostavljanje zavisi od odredišta koje klijenti već znaju: javne adrese, prosljeđivanja porta ispred nje i slušaoca unutra. Proslijeđeni saobraćaj zavisi od druge odluke donesene nakon što paket uđe u tunel, kada host prepiše svoj izvor kako bi odgovori mogli naći put nazad.

Promjena adrese kvari samo drugu odluku, i zato se simptom čita kao "povezano ali bez interneta". To objašnjava i zašto uobičajene provjere na strani klijenta izgledaju zdravo: rukovanje se završi, klijent dobije adresu, a ping na tunelsku adresu servera može čak i odgovoriti. Sati se troše na klijentu zbog kvara koji živi na drugoj strani, zato je tabela pravila prvo mjesto za pogledati.

Pročitajte pravilo i njegove brojače prije izmjene

Izlistajte pravila prevođenja s brojačima i uporedite konfigurisani izvor s adresama koje host zaista drži. Pravilo prepisano na mrtvu adresu obično pokazuje saobraćaj na ulaznom putu, jer paketi do njega stižu i prevode se, a na povratnom putu ništa.

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

Provjerite tri polja dok ste tamo: skup u podudaranju izvora, izlazni interfejs ako ga pravilo navodi, i izuzetak koji čuva saobraćaj između tunela od prepisivanja. Taj izuzetak je lako izgubiti tokom izmjene, a njegov gubitak čini da saobraćaj između partnera izgleda ispravno dok njegovi odgovori idu čudnim putem.

Ako brojači stoje na nuli, paketi nikada ne stižu do ovog pravila i adresa nije trenutni problem. Potražite konkurentsko pravilo ranije u lancu, što se dešava kada neko doda zamjenu umjesto da uredi original. Uporedite brojeve pravila s izlazom koji ste zapisali prije minute. Redoslijed je dio konfiguracije, a ne kozmetički detalj.

Zamijenite izvor ili prestanite da ga navodite

Kada host ima stabilnu adresu, zamijenite pravilo na mjestu umjesto da dodajete još jedno. Zamjena po broju pravila čuva redoslijed od kojeg zavisi ostatak lanca.

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

Kada se adresa dodjeljuje dinamički, ne navodite nikakav izvor i pustite jezgro da izabere trenutni s izlaznog interfejsa. Ta varijanta preživi sljedeću selidbu bez izmjene, po cijeni skrivanja koja je adresa korištena.

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

Potvrdite da je prosljeđivanje IPv4 još omogućeno kroz upravljanu konfiguraciju, pa učinite pravilo trajnim mehanizmom same distribucije. Izmjena napravljena samo u pokrenutom jezgru vraća se sa sljedećim ponovnim pokretanjem, obično tokom prozora održavanja koji niko ne povezuje s promjenom.

Dva načina da zamjenu uradite pogrešno

Prevođenje skupa na tunelsku adresu servera umjesto na njegovu LAN adresu šalje odgovore pravo nazad u tunel, gdje se rutiraju prema klijentu koji ih nikada nije tražio. Veza stane na način koji izgleda kao petlja rutiranja, jer to i jeste.

Nagomilavanje drugog prevođenja iznad starog je druga greška. Prvo pravilo koje se podudari pobjeđuje, pa zastarjeli unos nastavlja obrađivati pakete dok se ne izbriše, a brojači novog pravila ostaju na nuli dok svi krive zamjenu. Izbrišite duplikat prije nego što dodate bilo šta novo. Zatim pročitajte listu još jednom i potvrdite da se sa skupom podudara tačno jedno prevođenje.

Ako tunel nosi i IPv6, ponovite cijeli pregled na drugom steku. IPv6 podrazumijevana ruta bez prevođenja i bez rutiranog prefiksa pada jednako tiho, a to je lako zaboraviti jer sve iznad izgleda identično.

Dolazne usluge traže suprotno prevođenje

Usluga na VPN klijentu koja mora biti dostupna spolja traži prevođenje odredišta, a ne izvora: javni port se prepisuje na tunelsku adresu klijenta prije nego uđe. Put prosljeđivanja zatim traži izričito pravilo koje dopušta taj saobraćaj.

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

Nikada ne prevodite port koji nosi sam tunel, jer to prepisivanje prekida vezu koja drži uslugu dostupnom. Držite tunelski port potpuno izvan pravila odredišta. Na kraju provjerite s oba kraja: brojači na novom pravilu, kratak snimak na tunelskom uređaju i jedan zahtjev na adresu unutar tunela prije nego što probate javnu.