VPN amaierako puntuaren izena versus zerbitzu pribatuaren izena: bi jabe

Bi izenek adar bera deskriba dezakete eta erabat desberdinak diren galderei erantzun. vpn.branch.example urruneko pare bati VPN amaierako puntua non aurkitu esaten dio, eta edozein tunel existitu aurretik ebatzita egon behar du. inventory.branch.example erabiltzaile baimendu bati aplikazio pribatu bat non bizi den esaten dio, eta tunela martxan dagoenean bakarrik du garrantzia. Bietako bat mantentzeak ez dio besteari ezer egiten.

Izenda itzazu bi erregistroak, horietako edozein arazteko

Idatzi biak beren jabeekin. Amaierako puntuarentzat, idatzi nor arduratzen den helbide publikoa eguneratzeaz eta nola berritzen duen VPN bezeroak bere erantzuna. Zerbitzuarentzat, idatzi nor den helbide pribatuaren jabea, zein gunek gordetzen duen erregistroa eta zein ebazlek eman behar duten haren berri.

Zerrenda labur horrek arlo honetako diagnosi oker arruntena eragozten du: funtzionatzen duen adar-tunel bat berrabiaraztea, erabat bere barnean bizi den erregistro bat konpontzeko. Tunela zerbitzu-izenaren garraioa da; ez da haren agintaritza.

Aldaketa bat proposatzen denean, galdetu bi erregistroetatik zeini eragiten dion. Inork erantzun ezin badu, aldaketa ez dago programatzeko prest.

Amaierako puntua edozein tunel existitu aurretik ebatzita egon behar da

Demagun adarraren internet-konexioak helbide publiko berri bat jasotzen duela. Amaierako puntuaren eguneratzaileak helbide berria argitaratzen du, eta urruneko VPN inplementazioak erantzun aldatu hori irakurtzeko gai izan behar du. Erantzun hori ematen duen edozein ebazlek tunelik gabe iristeko modukoa izan behar du, bestela bezeroa aurkitzen ez duen gauzarekin konektatu ondoren bakarrik ebatzi dezakeen izen baten atzetik dabil.

Hasierako karga-mendekotasun hori argi esateko modukoa da, erraza baita ustekabean sortzen barneko ebazle guztiak VPNaren atzean daudenean. Mantendu tunelaren aurreko bide bat amaierako puntuaren bilaketarako, eta egiaztatu bezeroaren berrkonexio-jokabidea erantzun berria berehala hartzen dela suposatu beharrean.

DNS dinamikoak mugak ere baditu, erregistroaren eguneraketak ezin gaindituak. Erregistro bat eguneratzeak ez du suebakiko porturik irekitzen, ez du NAT mapatzerik sortzen eta ez du pare-identitaterik frogatzen. Ate itxia duen helbide argitaratu batek zuzen ebatzi eta ezeri konektatu ezin dion bezero bat ematen du.

Azkenik, martxan dagoen bezero batek cachean gordetako amaierako puntua erabiltzen jarrai dezake berriro konektatu arte. Bereizi argitaratzea, cachea eta berrkonexio-politika zure oharretan, pare zaharkitu bat eguneratzaile hautsitzat har ez dadin.

Zerbitzu-izenak aplikazioa non bizi den deskribatzen du

Orain demagun tunelak osasuntsu jarraitzen duela baina inbentario-zerbitzaria 172.26.14.20 helbidetik 172.26.14.35 helbidera lekualdatzen dela. Amaierako puntuaren erregistro publikoa ez da kaltetua, zerbitzu pribatuaren erregistroak aldatu behar duen bitartean. Zerbitzu horretarako gordetako helbide bat edo esleipen estatiko bat erabiltzeak arraroagoa egiten du; baimendutako eguneratze-bide batek asmoa deneko kasuak kudeatzen ditu.

Hemen bi eguneratze-mekanismo nahasten dira. RFC 2136 guneko DNS erregistroak gehitu eta ezabatzeko protokolo bat definitzen du, DNS dinamikoko hornitzaile komertzal batek erabat desberdina den HTTP API bat eskain baitezake beste helburu baterako. Bata erabiltzeak ez du esan nahi bestea zure ingurunean dagoenik. Egiaztatu zure gunek benetan zein mekanismo onartzen duen hari eguneratzaile bat idatzi aurretik.

Erantzun pribatu zuzena lehen baldintza besterik ez da. Urruneko deitzaile batek erabil dezan, bezeroak eremu pribatua daraman ebazle bat behar du, ebazle horri kontsultak baimenduko dizkion politika bat, eta itzultzen den helbiderako birbidalketa. Bezeroak iritsi ezin dezakeen helbide batera ebazten duen izen batek zerbitzari-matxurako denbora-muga sortzen du.

Probatu bi bideak bereizita

Egiaztatu amaierako puntua tunelaren kanpotik eta zerbitzua barrutik, eta gorde emaitzak bi gertaera independente gisa:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Lehenengo kontsultak huts egiten badu, arazoa argitalpen publikoa edo tunelaren aurreko ebazpen-bidea da, eta barne-aldaketak ez du lagunduko. Bigarrenak helbide bat itzultzen badu baina hirugarrenak tunelaren bidezko biderik erakusten ez badu, DNS geruza ondo dago eta birbidaltze-politika ez.

Exekutatu bikotea helbide-aldaketa bakoitzaren ondoren, eta idatzi zein erregistro mugitu den. «DNS eguneratu da» besterik esaten ez duen transferentziak hurrengo ingeniariari asmatzen uzten dio zein bizitza-ziklo gertatu zen benetan.