Po zmene IP adresy servera pravidlo SNAT stále uvádza starú

Server sa presťahoval na novú adresu, klienti sa stále pripájajú a nič z toho, čo pošlú, sa nedostane na internet. Práve to rozdelenie je stopa: počúvajúci socket a presmerovanie portu prežili sťahovanie, takže tunel naskočí, zatiaľ čo preklad zdroja aplikovaný na preposlané pakety stále uvádza adresu, ktorú hostiteľ už nevlastní. Odpovede na tieto prepísané pakety smerujú k stroju, ktorý už tam nie je.

Pripojenie a preposielanie zlyhávajú na rôznych miestach

Nadviazanie závisí od koncového bodu, ktorý klienti už poznajú: verejná adresa, presmerovanie portu pred ňou a poslucháč vnútri. Preposielaná prevádzka závisí od druhého rozhodnutia prijatého po tom, ako paket vstúpi do tunela, keď hostiteľ prepíše svoj zdroj, aby odpovede našli cestu späť.

Zmena adresy pokazí len druhé rozhodnutie, a preto sa príznak číta ako "pripojené, ale bez internetu". Vysvetľuje to aj to, prečo obvyklé kontroly na strane klienta vyzerajú zdravo: handshake sa dokončí, klient dostane adresu a ping na tunelovú adresu servera môže dokonca odpovedať. Hodiny sa trávia na klientovi pre poruchu, ktorá sídli na druhej strane, preto je tabuľka pravidiel prvým miestom, kam sa pozrieť.

Prečítajte si pravidlo a jeho počítadlá pred úpravou

Vypíšte pravidlá prekladu s počítadlami a porovnajte nakonfigurovaný zdroj s adresami, ktoré hostiteľ skutočne drží. Pravidlo prepísané na mŕtvu adresu zvyčajne ukazuje prevádzku na prichádzajúcej ceste, pretože pakety sa k nemu dostanú a preložia sa, a na ceste späť nič.

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

Prezrite si tri polia, kým ste tam: fond v porovnaní zdroja, výstupné rozhranie, ak ho pravidlo uvádza, a vylúčenie, ktoré bráni prepisu prevádzky medzi tunelmi. Toto vylúčenie sa pri úprave ľahko stratí a jeho strata spôsobí, že prevádzka medzi protistranami vyzerá funkčne, zatiaľ čo jej odpovede idú zvláštnou cestou.

Ak počítadlá stoja na nule, pakety sa k tomuto pravidlu nikdy nedostanú a adresa nie je súčasný problém. Hľadajte konkurenčné pravidlo vyššie v reťazci, čo sa stáva, keď niekto pridá náhradu namiesto úpravy originálu. Porovnajte čísla pravidiel s výstupom, ktorý ste si pred minútou poznamenali. Poradie je súčasť konfigurácie, nie kozmetický detail.

Nahraďte zdroj, alebo prestaňte nejaký uvádzať

Keď má hostiteľ stabilnú adresu, nahraďte pravidlo na mieste, namiesto toho, aby ste pridávali ďalšie. Nahradenie podľa čísla pravidla zachová poradie, na ktorom závisí zvyšok reťazca.

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

Keď sa adresa prideľuje dynamicky, neuvádzajte žiadny zdroj a nechajte jadro vybrať ten aktuálny z výstupného rozhrania. Tento variant prežije ďalšie sťahovanie bez úpravy, za cenu toho, že skrýva, ktorá adresa bola použitá.

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

Overte, že preposielanie IPv4 je stále povolené spravovanou konfiguráciou, a potom pravidlo uložte natrvalo vlastným mechanizmom distribúcie. Zmena vykonaná len v bežiacom jadre sa vráti pri ďalšom reštarte, zvyčajne počas servisného okna, ktoré nikto so zmenou nespája.

Dva spôsoby, ako náhradu urobiť zle

Preklad fondu na tunelovú adresu servera namiesto jeho LAN adresy pošle odpovede priamo späť do tunela, kde sú smerované ku klientovi, ktorý o ne nikdy nežiadal. Spojenie uviazne spôsobom, ktorý vyzerá ako smerovacia slučka, pretože to slučka je.

Naskladanie druhého prekladu nad starý je druhá chyba. Vyhráva prvé zodpovedajúce pravidlo, takže zastaraný záznam ďalej spracúva pakety, kým sa nevymaže, a počítadlá nového pravidla zostávajú na nule, zatiaľ čo všetci vinia náhradu. Vymažte duplikát, kým čokoľvek nové pridáte. Potom zoznam prečítajte ešte raz a overte, že fondu zodpovedá práve jeden preklad.

Ak tunel nesie aj IPv6, zopakujte celú revíziu na druhom zásobníku. Predvolená trasa IPv6 bez prekladu a bez smerovaného prefixu zlyháva rovnako ticho a ľahko sa zabudne, pretože všetko nad ňou vyzerá rovnako.

Prichádzajúce služby potrebujú opačný preklad

Služba na klientovi VPN, ktorá musí byť dostupná zvonku, potrebuje preklad cieľa, nie zdroja: verejný port sa pred vstupom prepíše na tunelovú adresu klienta. Cesta preposielania potom potrebuje výslovné pravidlo, ktoré túto prevádzku povolí.

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

Nikdy neprekladajte port, ktorý nesie samotný tunel, pretože tento prepis prerušuje spojenie, ktoré drží službu dostupnou. Držte tunelový port úplne mimo pravidiel cieľa. Nakoniec to overte z oboch strán: počítadlá na novom pravidle, krátky záznam na tunelovom zariadení a jedna požiadavka na adresu vnútri tunela, kým skúsite verejnú.