Hairpin-NAT: wêrom't it VPN-einpunt fan binnen út mislearret

In VPN-tsjinner dy't fan in mobyl netwurk antwurdet en fan 'e bank ôf mislearret, is meastentiids gjin sertifikaatprobleem. De klant binnen it LAN freget de router om in pakket te oersetten wêrfan't de bestimming it eigen iepenbiere adres fan 'e router is, wat betsjut dat it pakket nei bûten moat en direkt werom nei binnen. Dy manoeuvre hjit hairpinning, en in soad routers ymplementearje it óf hielendal net óf allinnich as in kontrôlefakje oan stiet. Krekt it slagjen fan 'e bûtenste test makket it betiizjend, om't it bewissiget dat de lústerer en de trochstjoerregel yn oarder binne.

It pakket giet nei bûten en komt werom nei binnen

Folgje it pakket. De klant lost de iepenbiere namme op, ferbynt mei it iepenbiere adres, en de bestimming-NAT fan 'e router skriuwt de bestimming oer nei de ynterne tsjinner. It antwurd fan 'e tsjinner is adressearre oan it LAN-adres fan 'e klant, dus it giet werom troch de LAN-ynterface fan 'e router sûnder ea de NAT-regel te passearjen dy't de boarne werom oersetten hie.

No krijt de klant in pakket fan in adres dêr't er nea wat hinne stjoerd hat, en smyt it fuort. Dy asymmetry is de hiele stoaring.

RFC 4787 beskriuwt it gedrach dat fan in NAT ferwachte wurdt yn dit gefal, en de koarte ferzje is dat it yn 'e praktyk opsjoneel is, sels dêr't it teoretysk fêstlein is. Guon routers neame de ynstelling NAT loopback, oaren hairpin NAT of NAT reflection, en guon litte hielendal neat sjen. In router dy't it net hat, is net ferkeard konfigurearre; hy docht it gewoane ding, en de oplossing heart earne oars. Meitsje út in mislearre pleatslike test net op dat de iepenbiere trochstjoerregel ferkeard is.

Kontrôle 1: test de beide paden apart

Ferbynt fan bûten it LAN mei itselde profyl dat in echte brûker brûke soe en befêstigje dat de sesje ta stân komt. Ferbynt fan binnen mei itselde profyl nei it iepenbiere adres en skriuw de krekte flater en de tiid op.

In krekte pleatslike test hâldt de hostnamme en ferfangt allinnich it adres: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ stjoert it fersyk nei it iepenbiere adres wylst er noch de juste tsjinnernamme presintearret. Dat skiedt in namme-oplossingsprobleem fan in oersettingsprobleem, dy't maklik trochinoar helle wurde as deselde namme fan in kafee ôf wurket. Tink derom oft de klant by TCP-ferbining mislearret of letter by TLS, om't it earste op oersetting wiist en it twadde op identiteit.

Kontrôle 2: lês wat de tsjinner sjocht

De nuttichste observaasje is it sicht fan 'e tsjinner. Start in opname op 'e VPN-host filtrarre op it LAN-adres fan 'e klant en op it LAN-adres fan 'e router, en werhelje dan de pleatslike poging. As der neat oankomt, hat it pakket de oersetting net oerlibbe.

As der in ferbining oankomt fan it LAN-adres fan 'e router ynstee fan dat fan 'e klant, bart der hairpinning en is de boarne oerskreaun. Dat is in wurkjende konfiguraasje, gjin stoaring.

Kontrôle 3: reparearje it sûnder it bûtenste paad oan te reitsjen

Der binne trije stipe foarmen, yn tanimmende oarder fan ynfloed. De smelste is split DNS: publisearje in yntern record sadat deselde tsjinnernamme foar klanten op it LAN nei it ynterne adres oplost, wat it iepenbiere paad hielendal mijt. De folgjende is de dokumintearre loopback- of reflection-opsje fan 'e router oansette, as dy der is, en dy allinnich op dizze tsjinst tapasse. De breedste is in source-NAT-regel op 'e router dy't ferkear fan it LAN nei de tsjinner oerskriuwt sadat it antwurd troch de router weromkomt; op in Linux-router is dat in MASQUERADE-regel yn POSTROUTING dy't by it adres en de poarte fan 'e tsjinner past. Alle trije litte it eksterne paad ûnoantaast, en dat is de eigenskip dy't bewarre wurde moat.

Ferbriedzje gjin net-relatearre poartetrochstjoering om it pleatslike paad op it eksterne lykje te litten, en ferpleats de tsjinst net nei in oare poarte om it probleem te ûntwykjen. Beide feroarings feroarje wat de bûtenwrâld berikke kin om eat te reparearjen dat allinnich de binnenwrâld sjocht.

Split DNS hat ien falstrik dy't it neamen wurdich is. It ferfangen fan in hostnamme troch in willekeurige IP feroaret wat de klant falidearret, dus it ynterne record moat noch by de namme yn it sertifikaat passe.

Kontrôle 4: ferifiearje dêrnei beide paden

Werhelje de eksterne poging fan bûten it LAN, werhelje de ynterne poging mei itselde profyl, en befêstigje dat it tsjinnerloch twa aparte slagge sesjes sjen lit ynstee fan ien sukses en ien stilte. Kontrolearje dan oft oare klanten de lústerer noch berikke en oft de rûtes nei privee boarnen ûnferoare binne.

Hâld it ferslach koart: hokker adres elke klant brûkte, wat de tsjinner seach en hokker fan 'e trije reparaasjes tapast waard. De hairpinning-easken fan RFC 4787 binne hjir de referinsje foar wat fan in NAT ferwachte wurdt, en se ferklearje wêrom't in router sûnder de funksje him normaal hâldt en draacht. In pleatslike stoaring dy't de bûtenwrâld net neimeitsje kin, is in oersettingsfraach oant it tsjinoerstelde bewiisd is, dus test it as sadanich.