Po změně IP adresy serveru pravidlo SNAT stále uvádí starou

Server se přestěhoval na novou adresu, klienti se stále připojují a nic z toho, co pošlou, se nedostane na internet. Právě to rozdělení je stopa: naslouchající socket a přesměrování portu přežily stěhování, takže tunel naskočí, zatímco překlad zdroje aplikovaný na předávané pakety stále uvádí adresu, kterou hostitel už nevlastní. Odpovědi na tyto přepsané pakety míří ke stroji, který už tam není.

Připojení a předávání selhávají na různých místech

Navázání závisí na koncovém bodu, který klienti už znají: veřejná adresa, přesměrování portu před ní a posluchač uvnitř. Předávaný provoz závisí na druhém rozhodnutí, které se učiní poté, co paket vstoupí do tunelu, kdy hostitel přepíše svůj zdroj, aby odpovědi našly cestu zpět.

Změna adresy rozbije jen druhé rozhodnutí, a proto se symptom čte jako "připojeno, ale bez internetu". Vysvětluje to také, proč obvyklé kontroly na straně klienta vypadají zdravě: handshake se dokončí, klient dostane adresu a ping na tunelovou adresu serveru může dokonce odpovědět. Hodiny se tráví na klientovi kvůli závadě, která sídlí na druhé straně, a proto je tabulka pravidel prvním místem, kam se podívat.

Přečtěte si pravidlo a jeho čítače před úpravou

Vypište pravidla překladu s čítači a porovnejte nakonfigurovaný zdroj s adresami, které hostitel skutečně drží. Pravidlo přepsané na mrtvou adresu obvykle ukazuje provoz na příchozí cestě, protože pakety se k němu dostanou a přeloží se, a na cestě zpět nic.

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

Prohlédněte tři pole, dokud jste tam: fond v porovnání zdroje, výstupní rozhraní, pokud ho pravidlo uvádí, a vyloučení, které brání přepisu provozu mezi tunely. Toto vyloučení se při úpravě snadno ztratí a jeho ztráta způsobí, že provoz mezi protějšky vypadá funkčně, zatímco jeho odpovědi jdou podivnou cestou.

Pokud čítače stojí na nule, pakety se k tomuto pravidlu nikdy nedostanou a adresa není současný problém. Hledejte konkurenční pravidlo výše v řetězci, což se stává, když někdo přidá náhradu místo úpravy originálu. Porovnejte čísla pravidel s výstupem, který jste si před minutou poznamenali. Pořadí je součást konfigurace, ne kosmetický detail.

Nahraďte zdroj, nebo přestaňte nějaký uvádět

Když má hostitel stabilní adresu, nahraďte pravidlo na místě, místo abyste přidávali další. Nahrazení podle čísla pravidla zachová pořadí, na kterém závisí zbytek řetězce.

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

Když je adresa přidělována dynamicky, neuvádějte žádný zdroj a nechte jádro vybrat ten aktuální z výstupního rozhraní. Tato varianta přežije další stěhování bez úpravy, za cenu toho, že skrývá, která adresa byla použita.

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

Ověřte, že předávání IPv4 je stále povoleno spravovanou konfigurací, a poté pravidlo uložte trvale vlastním mechanismem distribuce. Změna provedená jen v běžícím jádře se vrátí s dalším restartem, obvykle během servisního okna, které nikdo se změnou nespojí.

Dva způsoby, jak náhradu provést špatně

Překlad fondu na tunelovou adresu serveru místo jeho LAN adresy pošle odpovědi přímo zpět do tunelu, kde jsou směrovány ke klientovi, který o ně nikdy nežádal. Spojení uvízne způsobem, který vypadá jako směrovací smyčka, protože to smyčka je.

Naskládání druhého překladu nad starý je druhá chyba. Vyhrává první odpovídající pravidlo, takže zastaralý záznam dál zpracovává pakety, dokud se nesmaže, a čítače nového pravidla zůstávají na nule, zatímco všichni viní náhradu. Smažte duplikát, než cokoli nového přidáte. Potom seznam přečtěte ještě jednou a ověřte, že fondu odpovídá právě jeden překlad.

Pokud tunel nese i IPv6, zopakujte celou revizi na druhém zásobníku. Výchozí trasa IPv6 bez překladu a bez směrovaného prefixu selhává stejně tiše a snadno se zapomene, protože všechno nad ní vypadá stejně.

Příchozí služby potřebují opačný překlad

Služba na klientovi VPN, která musí být dostupná zvenčí, potřebuje překlad cíle, ne zdroje: veřejný port se před vstupem přepíše na tunelovou adresu klienta. Cesta předávání pak potřebuje výslovné pravidlo, které tento provoz povolí.

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

Nikdy nepřekládejte port, který nese samotný tunel, protože tento přepis přeruší spojení, které drží službu dostupnou. Držte tunelový port zcela mimo pravidla cíle. Nakonec to ověřte z obou stran: čítače na novém pravidle, krátký záznam na tunelovém zařízení a jeden požadavek na adresu uvnitř tunelu, než zkusíte veřejnou.