Hairpin NAT: miért nem működik a VPN végpont belülről

Egy VPN-kiszolgáló, amely mobilhálózatból válaszol, de a kanapéról nem működik, általában nem tanúsítványprobléma. A LAN-on belüli kliens arra kéri a routert, hogy fordítson le egy csomagot, amelynek célja magának a routernek a nyilvános címe, ami azt jelenti, hogy a csomagnak ki kell mennie és azonnal vissza kell jönnie. Ezt a manővert hairpinningnek nevezik, és sok router vagy egyáltalán nem valósítja meg, vagy csak akkor, ha egy jelölőnégyzet be van kapcsolva. Épp a kívülről végzett teszt sikeressége teszi zavaróvá, mert bizonyítja, hogy a figyelő és az átirányítási szabály rendben van.

A csomag kimegy és visszajön

Kövessük a csomagot. A kliens feloldja a nyilvános nevet, csatlakozik a nyilvános címhez, és a router cél-NAT-ja átírja a célt a belső kiszolgálóra. A kiszolgáló válasza a kliens LAN-címére van címezve, ezért a router LAN-interfészén keresztül megy vissza, soha nem haladva át azon a NAT-szabályon, amely visszafordította volna a forrást.

Most a kliens egy olyan címről kap csomagot, ahová soha nem küldött semmit, és eldobja. Ez az aszimmetria a teljes hiba.

Az RFC 4787 leírja, milyen viselkedés várható el egy NAT-tól ebben az esetben, és a rövid változat az, hogy a gyakorlatban opcionális, még ott is, ahol elméletben meghatározott. Egyes routerek NAT loopbacknek nevezik a beállítást, mások hairpin NAT-nak vagy NAT reflectionnek, és van, amelyik semmit nem tesz elérhetővé. Az a router, amelyből hiányzik, nincs hibásan beállítva; a szokásos dolgot teszi, és a javítás máshová tartozik. Ne következtessünk egy sikertelen helyi tesztből arra, hogy a nyilvános átirányítási szabály hibás.

1. ellenőrzés: teszteljük a két útvonalat külön

A LAN-on kívülről csatlakozzunk ugyanazzal a profillal, amelyet egy valódi felhasználó használna, és erősítsük meg, hogy a munkamenet létrejön. Belülről csatlakozzunk a nyilvános címhez ugyanazzal a profillal, és jegyezzük fel a pontos hibát és az időpontot.

Egy pontos helyi teszt megtartja a gazdanevet, és csak a címet írja felül: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ elküldi a kérést a nyilvános címre, miközben továbbra is a helyes kiszolgálónevet mutatja. Ez elválasztja a névfeloldási problémát a fordítási problémától, amelyek könnyen összekeverhetők, ha ugyanaz a név egy kávézóból működik. Jegyezzük fel, hogy a kliens a TCP-kapcsolatnál vagy később a TLS-nél vall kudarcot, mert az első fordításra, a második identitásra utal.

2. ellenőrzés: olvassuk el, mit lát a kiszolgáló

A leghasznosabb megfigyelés a kiszolgáló nézete. Indítsunk rögzítést a VPN-gazdán a kliens LAN-címére és a router LAN-címére szűrve, majd ismételjük meg a helyi kísérletet. Ha semmi nem érkezik, a csomag nem élte túl a fordítást.

Ha a kapcsolat a router LAN-címéről érkezik a kliensé helyett, hairpinning történik, és a forrás átíródott. Ez működő konfiguráció, nem hiba.

3. ellenőrzés: javítsuk ki a külső útvonal érintése nélkül

Három támogatott forma létezik, a hatás sugarának növekvő sorrendjében. A legszűkebb a megosztott DNS: tegyünk közzé egy belső rekordot, hogy ugyanaz a kiszolgálónév a LAN-on lévő klienseknek a belső címre oldódjon fel, ami teljesen elkerüli a nyilvános útvonalat. A következő a router dokumentált loopback vagy reflection opciójának engedélyezése, ha van ilyen, és csak erre a szolgáltatásra való alkalmazása. A legszélesebb egy source-NAT szabály a routeren, amely átírja a LAN-ról érkező forgalmat a kiszolgálóra, hogy a válasz a routeren keresztül térjen vissza; Linux-routeren ez egy MASQUERADE szabály a POSTROUTING láncban, amely a kiszolgáló címére és portjára illeszkedik. Mindhárom érintetlenül hagyja a külső útvonalat, és ezt a tulajdonságot kell megőrizni.

Ne szélesítsük ki a nem kapcsolódó porttovábbítást, hogy a helyi útvonal hasonlítson a külsőre, és ne helyezzük át a szolgáltatást másik portra a probléma kikerüléséhez. Mindkét változtatás azt módosítja, mit érhet el a külvilág, hogy kijavítson valamit, amit csak a belső világ lát.

A megosztott DNS-nek van egy csapdája, amelyet érdemes megnevezni. Ha egy gazdanevet tetszőleges IP-re cserélünk, megváltozik, mit ellenőriz a kliens, ezért a belső rekordnak továbbra is egyeznie kell a tanúsítvány nevével.

4. ellenőrzés: utána ellenőrizzük mindkét útvonalat

Ismételjük meg a külső kísérletet a LAN-on kívülről, ismételjük meg a belső kísérletet ugyanazzal a profillal, és erősítsük meg, hogy a kiszolgáló naplója két külön sikeres munkamenetet mutat, nem egy sikert és egy csendet. Utána ellenőrizzük, hogy a többi kliens továbbra is eléri a figyelőt, és hogy a privát erőforrásokhoz vezető útvonalak változatlanok.

Tartsuk rövidnek a feljegyzést: melyik kliens melyik címet használta, mit látott a kiszolgáló, és a három javítás közül melyiket alkalmaztuk. Az RFC 4787 hairpinning-követelményei adják a hivatkozást arra, mi várható el itt egy NAT-tól, és megmagyarázzák, miért viselkedik normálisan a funkció nélküli router. Az a helyi hiba, amelyet a külvilág nem tud reprodukálni, fordítási kérdés mindaddig, amíg az ellenkezője be nem bizonyosodik, ezért úgy teszteljük.