Hairpin NAT: proč koncový bod VPN nefunguje zevnitř

VPN server, který odpovídá z mobilní sítě a selhává z gauče, obvykle není problém certifikátu. Klient uvnitř LAN žádá router, aby přeložil paket, jehož cílem je vlastní veřejná adresa routeru, což znamená, že paket musí odejít a hned se vrátit. Tento manévr se nazývá hairpinning a řada routerů ho buď neimplementuje, nebo ho zapíná jen při zaškrtnutém políčku. Právě úspěšný test zvenčí mate, protože dokazuje, že posluchač i pravidlo přesměrování jsou v pořádku.

Paket odejde a vrátí se

Sledujte paket. Klient přeloží veřejné jméno, připojí se na veřejnou adresu a cílový NAT routeru přepíše cíl na interní server. Odpověď serveru je adresována na LAN adresu klienta, takže se vrací přes LAN rozhraní routeru, aniž by kdy prošla pravidlem NAT, které by vrátilo zdroj.

Nyní klient obdrží paket z adresy, na kterou nikdy nic neposlal, a zahodí ho. Touto asymetrií je celá závada.

RFC 4787 popisuje chování, které se od NAT v tomto případě očekává, a krátká verze je, že v praxi je volitelné, i tam kde je teoreticky specifikováno. Některé routery nastavení nazývají NAT loopback, jiné hairpin NAT nebo NAT reflection a některé neukazují nic. Router, který to nemá, není špatně nastavený; dělá obvyklou věc a oprava patří jinam. Neusuzujte z neúspěšného lokálního testu, že veřejné pravidlo přesměrování je špatné.

Kontrola 1: testujte obě cesty odděleně

Zvenčí LAN se připojte stejným profilem, jaký by použil skutečný uživatel, a potvrďte, že se relace naváže. Zevnitř se připojte na veřejnou adresu stejným profilem a zaznamenejte přesnou chybu a čas.

Přesný lokální test zachová jméno hostitele a nahradí jen adresu: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ odešle požadavek na veřejnou adresu a přitom stále předkládá správné jméno serveru. To odděluje problém překladu jmen od problému překladu adres, které se snadno zamění, když stejné jméno funguje z kavárny. Poznamenejte, zda klient selže při TCP připojení, nebo později u TLS, protože první ukazuje na překlad a druhé na identitu.

Kontrola 2: přečtěte, co vidí server

Nejužitečnější pozorování je pohled serveru. Spusťte odchyt na VPN hostiteli filtrovaný na LAN adresu klienta a na LAN adresu routeru, pak lokální pokus zopakujte. Pokud nic nedorazí, paket překlad nepřežil.

Pokud spojení dorazí z LAN adresy routeru místo z adresy klienta, hairpinning probíhá a zdroj byl přepsán. To je funkční konfigurace, ne závada.

Kontrola 3: opravte to bez zásahu do vnější cesty

Existují tři podporované podoby, v rostoucím pořadí dopadu. Nejužší je rozdělený DNS: zveřejněte interní záznam, aby se stejné jméno serveru překládalo na interní adresu pro klienty v LAN, což veřejné cestě zcela vyhne. Další je zapnutí dokumentované volby loopback nebo reflection na routeru, pokud ji má, a její použití jen na tuto službu. Nejširší je pravidlo source-NAT na routeru, které přepisuje provoz z LAN na server, aby se odpověď vrátila přes router; na Linux routeru je to pravidlo MASQUERADE v POSTROUTING odpovídající adrese a portu serveru. Všechny tři nechávají vnější cestu nedotčenou, a to je vlastnost, kterou je třeba zachovat.

Nerozšiřujte nesouvisející přesměrování portů, aby lokální cesta vypadala jako vnější, a nepřesouvejte službu na jiný port, abyste problém obejšli. Obě změny mění, kam se vnější svět dostane, kvůli opravě něčeho, co vidí jen vnitřní svět.

Rozdělený DNS má jednu past, kterou stojí za to pojmenovat. Nahrazení jména hostitele libovolnou IP mění to, co klient ověřuje, takže interní záznam musí stále odpovídat jménu v certifikátu.

Kontrola 4: poté ověřte obě cesty

Zopakujte vnější pokus zvenčí LAN, zopakujte vnitřní pokus se stejným profilem a potvrďte, že protokol serveru ukazuje dvě oddělené úspěšné relace, nikoli jeden úspěch a jedno ticho. Pak zkontrolujte, že ostatní klienti stále dosáhnou posluchače a že trasy k privátním prostředkům se nezměnily.

Veďte záznam krátce: kterou adresu který klient použil, co server viděl a která ze tří oprav byla aplikována. Požadavky na hairpinning z RFC 4787 jsou referencí pro to, co se zde od NAT očekává, a vysvětlují, proč se router bez této funkce chová normálně. Lokální selhání, které vnější svět nedokáže reprodukovat, je otázkou překladu, dokud se neprokáže opak, takže ho tak i testujte.