Hairpin-NAT: miksi VPN-päätepiste ei toimi sisältä

VPN-palvelin, joka vastaa mobiiliverkosta mutta ei toimi sohvalta, ei yleensä ole varmenneongelma. LAN-verkon sisällä oleva asiakas pyytää reititintä kääntämään paketin, jonka kohde on reitittimen oma julkinen osoite, mikä tarkoittaa, että paketin on poistuttava ja tultava heti takaisin sisään. Tämä liike on nimeltään hairpinning, ja monet reitittimet joko eivät toteuta sitä tai tekevät sen vain, kun valintaruutu on käytössä. Juuri ulkoa tehdyn testin onnistuminen hämmentää, koska se osoittaa, että kuuntelija ja edelleenlähetyssääntö ovat kunnossa.

Paketti menee ulos ja tulee takaisin sisään

Seuraa pakettia. Asiakas selvittää julkisen nimen, yhdistää julkiseen osoitteeseen, ja reitittimen kohde-NAT kirjoittaa kohteen uudelleen sisäiseen palvelimeen. Palvelimen vastaus on osoitettu asiakkaan LAN-osoitteeseen, joten se palaa reitittimen LAN-liitännän kautta koskaan kulkematta sen NAT-säännön läpi, joka olisi kääntänyt lähteen takaisin.

Nyt asiakas vastaanottaa paketin osoitteesta, johon se ei koskaan lähettänyt mitään, ja hylkää sen. Tämä epäsymmetria on koko vika.

RFC 4787 kuvaa toimintaa, jota NAT:lta tässä tapauksessa odotetaan, ja lyhyt versio on, että käytännössä se on valinnainen myös siellä, missä se on teoriassa määritelty. Jotkut reitittimet kutsuvat asetusta nimellä NAT loopback, toiset nimellä hairpin NAT tai NAT reflection, ja jotkut eivät näytä mitään. Reititin, jolta se puuttuu, ei ole väärin konfiguroitu; se tekee tavallisen asian, ja korjaus kuuluu muualle. Älä päättele epäonnistuneesta paikallisesta testistä, että julkinen edelleenlähetyssääntö on väärä.

Tarkistus 1: testaa kaksi reittiä erikseen

Yhdistä LAN-verkon ulkopuolelta samalla profiililla, jota oikea käyttäjä käyttäisi, ja varmista, että istunto muodostuu. Yhdistä sisältä julkiseen osoitteeseen samalla profiililla ja kirjaa tarkka virhe ja kellonaika.

Tarkka paikallinen testi säilyttää isäntänimen ja korvaa vain osoitteen: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ lähettää pyynnön julkiseen osoitteeseen esittäen silti oikean palvelinnimen. Tämä erottaa nimien selvitysongelman käännösongelmasta, jotka sekoittuvat helposti, kun sama nimi toimii kahvilasta. Huomaa, epäonnistuuko asiakas TCP-yhteydessä vai myöhemmin TLS:ssä, koska ensimmäinen viittaa käännökseen ja toinen identiteettiin.

Tarkistus 2: lue, mitä palvelin näkee

Hyödyllisin havainto on palvelimen näkymä. Käynnistä kaappaus VPN-isännässä suodatettuna asiakkaan LAN-osoitteeseen ja reitittimen LAN-osoitteeseen, ja toista sitten paikallinen yritys. Jos mitään ei saavu, paketti ei selvinnyt käännöksestä.

Jos yhteys saapuu reitittimen LAN-osoitteesta eikä asiakkaan osoitteesta, hairpinning tapahtuu ja lähde kirjoitettiin uudelleen. Tämä on toimiva kokoonpano, ei vika.

Tarkistus 3: korjaa koskematta ulkoiseen reittiin

Tuettuja muotoja on kolme, vaikutuspiirin kasvavassa järjestyksessä. Kapein on jaettu DNS: julkaise sisäinen tietue, jotta sama palvelinnimi selvitetään LAN-verkon asiakkaille sisäiseksi osoitteeksi, mikä välttää julkisen reitin kokonaan. Seuraava on reitittimen dokumentoidun loopback- tai reflection-vaihtoehdon ottaminen käyttöön, jos sellainen on, ja sen soveltaminen vain tähän palveluun. Laajin on reitittimen source-NAT-sääntö, joka kirjoittaa LAN-verkosta tulevan liikenteen palvelimelle niin, että vastaus palaa reitittimen kautta; Linux-reitittimessä se on MASQUERADE-sääntö POSTROUTING-ketjussa, joka vastaa palvelimen osoitetta ja porttia. Kaikki kolme jättävät ulkoisen reitin ennalleen, ja se on säilytettävä ominaisuus.

Älä laajenna asiaankuulumatonta portin edelleenlähetystä, jotta paikallinen reitti muistuttaisi ulkoista, äläkä siirrä palvelua toiseen porttiin ongelman kiertämiseksi. Molemmat muutokset muuttavat sitä, mitä ulkomaailma voi tavoittaa, jotta korjattaisiin jotain, jonka vain sisämaailma näkee.

Jaetussa DNS:ssä on yksi ansa, joka kannattaa mainita. Isäntänimen korvaaminen mielivaltaisella IP:llä muuttaa sitä, mitä asiakas validoi, joten sisäisen tietueen on edelleen vastattava varmenteen nimeä.

Tarkistus 4: varmista molemmat reitit jälkeenpäin

Toista ulkoinen yritys LAN-verkon ulkopuolelta, toista sisäinen yritys samalla profiililla ja varmista, että palvelimen loki näyttää kaksi erillistä onnistunutta istuntoa eikä yhtä onnistumista ja yhtä hiljaisuutta. Tarkista sitten, että muut asiakkaat tavoittavat kuuntelijan ja että reitit yksityisiin resursseihin ovat ennallaan.

Pidä kirjaus lyhyenä: mitä osoitetta kukin asiakas käytti, mitä palvelin näki ja mikä kolmesta korjauksesta otettiin käyttöön. RFC 4787:n hairpinning-vaatimukset ovat viite siitä, mitä NAT:lta täällä odotetaan, ja ne selittävät, miksi ilman tätä ominaisuutta reititin käyttäytyy normaalisti. Paikallinen vika, jota ulkomaailma ei voi toistaa, on käännöskysymys kunnes toisin todistetaan, joten testaa sitä sellaisena.