Hairpin NAT: zergatik huts egiten duen VPN muturrak barrutik

Sare mugikor batetik erantzuten duen eta sofatik huts egiten duen VPN zerbitzari bat ez da normalean ziurtagiri arazoa. LAN barruko bezeroak routerrari eskatzen dio helmuga routerraren beraren helbide publikoa duen pakete bat itzultzeko, hau da, paketeak atera eta berehala sartu behar du. Maneiubra horri hairpinning deritzo, eta router askok ez dute ezartzen edo kontrol-lauki bat gaituta dagoenean soilik ezartzen dute. Kanpoko probak pasatzeak egiten du gauza nahasgarri, entzulea eta birbidaltze-araua ondo daudela frogatzen duelako.

Paketea atera eta berriro sartzen da

Jarraitu paketeari. Bezeroak izen publikoa ebazten du, helbide publikora konektatzen da, eta routerraren helmuga-NAT-ak helmuga barneko zerbitzarira birridazten du. Zerbitzariaren erantzuna bezeroaren LAN helbidera zuzenduta dago, beraz, routerraren LAN interfazearen bidez itzultzen da, iturria atzera itzuliko zukeen NAT araua inoiz zeharkatu gabe.

Orain bezeroak inoiz ezer bidali ez zion helbide batetik paketea jasotzen du, eta baztertu egiten du. Asimetria hori da hutsegite osoa.

RFC 4787-ak kasu honetan NAT bati espero zaion jokabidea deskribatzen du, eta bertsio laburra da praktikan hautazkoa dela, teorian zehaztuta dagoen tokietan ere. Router batzuek NAT loopback deitzen diote ezarpenari, besteek hairpin NAT edo NAT reflection, eta batzuek ez dute ezer erakusten. Hau ez duen router bat ez dago gaizki konfiguratuta; ohiko gauza egiten ari da, eta konponketa beste leku batekoa da. Ez ondorioztatu tokiko proba batek huts egiteak birbidaltze-arau publikoa oker dagoenik.

Egiaztapena 1: probatu bi bideak bereizita

LAN-etik kanpo, erabiltzaile erreal batek erabiliko lukeen profilean konektatu eta saioa ezartzen dela baieztatu. Barrutik, helbide publikora konektatu profil berean eta idatzi errore zehatza eta ordua.

Tokiko proba zehatz batek ostalari-izena gordetzen du eta helbidea soilik ordezkatzen du: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ eskaera helbide publikora bidaltzen du, aldi berean zerbitzari-izen zuzena aurkeztuz. Horrek izen-ebazpen arazoa itzulpen arazo batetik bereizten du, erraz nahasten direnak izen berak kafetegi batetik funtzionatzen duenean. Ohartu bezeroak TCP konexioan edo geroago TLS-en huts egiten duen, lehenak itzulpena adierazten duelako eta bigarrenak identitatea.

Egiaztapena 2: irakurri zerbitzariak zer ikusten duen

Behaketarik erabilgarriena zerbitzariaren ikuspegia da. Exekutatu harrapaketa bat VPN ostalarian, bezeroaren LAN helbidera eta routerraren LAN helbidera iragazita, eta gero errepikatu tokiko saiakera. Ezer iristen ez bada, paketeak ez du itzulpena gainditu.

Konexio bat bezeroaren helbidearen ordez routerraren LAN helbideetatik iristen bada, hairpinning gertatzen ari da eta iturria birridatzi da. Hau funtzionatzen duen konfigurazioa da, ez matxura.

Egiaztapena 3: konpondu kanpoko bidea ukitu gabe

Hiru forma onartu daude, eragin-erradioaren arabera handitzen direnak. Estuena DNS zatitua da: argitaratu barne-erregistro bat, zerbitzari-izen berak LANeko bezeroentzat barne-helbidera ebazteko, eta horrela bide publikoa erabat saihesten da. Hurrengoa routerraren loopback edo reflection aukera dokumentatua gaitzea da, badago, eta zerbitzu honi soilik aplikatzea. Zabalena routerrean source-NAT arau bat da, LAN-etik datorren trafikoa zerbitzarira birridazten duena, erantzuna routerretik itzul dadin; Linux router batean MASQUERADE araua da POSTROUTING katean, zerbitzariaren helbidearekin eta atakarekin bat egiten duena. Hirurek kanpoko bidea ukitugabe uzten dute, eta horixe da gorde beharreko propietatea.

Ez zabaldu erlaziorik gabeko ataka-birbidalketa bide lokala kanpokoa bezalakoa izan dadin, eta ez eraman zerbitzua beste ataka batera arazoa saihesteko. Bi aldaketek kanpoko munduak zer har dezakeen aldatzen dute, barneko munduak soilik ikusten duen zerbait konpontzeko.

DNS zatituak aipatzeko merezi duen tranpa bat du. Ostalari-izen bat IP arbitrario batekin ordezkatzeak bezeroak baliozkotzen duena aldatzen du, beraz barne-erregistroak ziurtagiriaren izenarekin bat etorri behar du oraindik.

Egiaztapena 4: egiaztatu bi bideak gero

Errepikatu kanpoko saiakera LAN-etik kanpo, errepikatu barneko saiakera profil berean, eta baieztatu zerbitzariaren erregistroak bi saio arrakastatsu bereizi erakusten dituela, arrakasta bat eta isiltasun bat izan beharrean. Gero egiaztatu beste bezero batzuek entzulea oraindik heltzen dutela eta baliabide pribatuetarako bideak ez direla aldatu.

Eduki erregistroa labur: zein helbide erabili zuen bezero bakoitzak, zer ikusi zuen zerbitzariak eta hiru konponketetatik zein aplikatu zen. RFC 4787-ren hairpinning baldintzak dira hemen NAT bati zer espero zaion erreferentzia, eta funtzio hori ez duen router bat zergatik normaltasunez jokatzen duen azaltzen dute. Kanpoko munduak erreproduzitu ezin duen tokiko hutsegite bat itzulpen kontua da kontrakoa frogatu arte, beraz probatu hala.