Hairpin NAT: prečo koncový bod VPN nefunguje zvnútra

VPN server, ktorý odpovedá z mobilnej siete a zlyháva z gauča, zvyčajne nie je problém certifikátu. Klient vnútri LAN žiada router, aby preložil paket, ktorého cieľom je vlastná verejná adresa routera, čo znamená, že paket musí odísť a hneď sa vrátiť. Tento manéver sa nazýva hairpinning a mnohé routery ho buď vôbec neimplementujú, alebo ho zapínajú len pri zaškrtnutom políčku. Práve úspešný test zvonka mätie, pretože dokazuje, že poslucháč aj pravidlo presmerovania sú v poriadku.

Paket odíde a vráti sa späť

Sledujte paket. Klient preloží verejné meno, pripojí sa na verejnú adresu a cieľový NAT routera prepíše cieľ na interný server. Odpoveď servera je adresovaná na LAN adresu klienta, takže sa vracia cez LAN rozhranie routera bez toho, aby kedy prešla pravidlom NAT, ktoré by vrátilo zdroj.

Teraz klient dostane paket z adresy, na ktorú nikdy nič neposlal, a zahodí ho. Touto asymetriou je celá porucha.

RFC 4787 opisuje správanie, ktoré sa od NAT v tomto prípade očakáva, a krátka verzia je, že v praxi je voliteľné, aj tam kde je teoreticky špecifikované. Niektoré routery nastavenie nazývajú NAT loopback, iné hairpin NAT alebo NAT reflection a niektoré neukazujú nič. Router, ktorý to nemá, nie je zle nakonfigurovaný; robí obvyklú vec a oprava patrí inam. Neusudzujte z neúspešného lokálneho testu, že verejné pravidlo presmerovania je nesprávne.

Kontrola 1: testujte obe cesty oddelene

Zvonku LAN sa pripojte rovnakým profilom, aký by použil skutočný používateľ, a potvrďte, že sa relácia nadviaže. Zvnútra sa pripojte na verejnú adresu rovnakým profilom a zaznamenajte presnú chybu a čas.

Presný lokálny test zachová meno hostiteľa a nahradí len adresu: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ odošle požiadavku na verejnú adresu a pritom stále predkladá správne meno servera. To oddeľuje problém prekladu mien od problému prekladu adries, ktoré sa ľahko zamieňajú, keď rovnaké meno funguje z kaviarne. Poznamenajte, či klient zlyhá pri TCP pripojení alebo neskôr pri TLS, pretože prvé ukazuje na preklad a druhé na identitu.

Kontrola 2: prečítajte, čo vidí server

Najužitočnejšie pozorovanie je pohľad servera. Spustite odchyt na VPN hostiteľovi filtrovaný na LAN adresu klienta a na LAN adresu routera, potom zopakujte lokálny pokus. Ak nič nedorazí, paket preklad neprežil.

Ak spojenie dorazí z LAN adresy routera namiesto adresy klienta, hairpinning prebieha a zdroj bol prepísaný. To je funkčná konfigurácia, nie porucha.

Kontrola 3: opravte to bez zásahu do vonkajšej cesty

Existujú tri podporované formy v rastúcom poradí dopadu. Najužšia je rozdelený DNS: zverejnite interný záznam, aby sa rovnaké meno servera prekladalo na internú adresu pre klientov v LAN, čo sa verejnej ceste úplne vyhne. Ďalšia je zapnutie dokumentovanej voľby loopback alebo reflection na routeri, ak ju má, a jej použitie len na túto službu. Najširšia je pravidlo source-NAT na routeri, ktoré prepisuje prevádzku z LAN na server, aby sa odpoveď vrátila cez router; na Linux routeri je to pravidlo MASQUERADE v POSTROUTING zodpovedajúce adrese a portu servera. Všetky tri nechávajú vonkajšiu cestu nedotknutú a to je vlastnosť, ktorú treba zachovať.

Nerozširujte nesúvisiace presmerovanie portov, aby lokálna cesta vyzerala ako vonkajšia, a nepresúvajte službu na iný port, aby ste problém obišli. Obe zmeny menia, kam sa vonkajší svet dostane, kvôli oprave niečoho, čo vidí len vnútorný svet.

Rozdelený DNS má jednu pascu, ktorú stojí za to pomenovať. Nahradenie mena hostiteľa ľubovoľnou IP mení to, čo klient overuje, takže interný záznam musí stále zodpovedať menu v certifikáte.

Kontrola 4: potom overte obe cesty

Zopakujte vonkajší pokus zvonku LAN, zopakujte vnútorný pokus s rovnakým profilom a potvrďte, že protokol servera ukazuje dve oddelené úspešné relácie, nie jeden úspech a jedno ticho. Potom skontrolujte, že ostatní klienti stále dosiahnu poslucháča a že trasy k privátnym prostriedkom sa nezmenili.

Veďte záznam krátko: ktorú adresu ktorý klient použil, čo server videl a ktorá z troch opráv bola použitá. Požiadavky na hairpinning z RFC 4787 sú referenciou pre to, čo sa tu od NAT očakáva, a vysvetľujú, prečo sa router bez tejto funkcie správa normálne. Lokálne zlyhanie, ktoré vonkajší svet nedokáže reprodukovať, je otázkou prekladu, kým sa nepreukáže opak, takže ho tak aj testujte.