LANeko ostalari-izenak huts egiten du VPN bidez: atzizkia, mDNS edo zona?
Izen labur bat bilaketa-atzizki batean oinarri daiteke, .local izen bat multicast-en eta konpainia-izen bat zona pribatu batean. Bide bakar batek ez du izen-zerbitzurik ematen.
Gailuaren ondoan, inprimagailuak izen labur bati erantzuten dio eta fitxategi-zerbitzariak ezizen bati. Tuneletik, bi izenak iraungitzen dira, haien helbideak oraindik funtzionatzen duten bitartean. Bideak bere lana egiten du; izen labur horiek funtziona zezaten egiten zuen izen-bideak ez zuen sekula tunela zeharkatu. Hiru mekanismok sortzen dute jokabide hori, eta bakoitzak zuzenketa desberdina behar du.
Hasi izena zein mekanismoren mende dagoen zehazten.
Modu desberdinean jokatzen duten hiru izen mota
Etiketa bakarreko izen batek, hala nola fileserver, normalean resolver-ak gehitzen duen DNS bilaketa-atzizki batean oinarritzen da. Atzizki hori sarritan tokiko DHCP alokairuarekin iristen da, beraz VPNetik helbideratzea lortzen duen urruneko bezeroak ez du hori ezagutzeko arrazoirik. Bide bat gehitzeak ez du atzizkia eramaten. Izen laburra izen gisa existitzeari uzten dio, atzean duen helbidea irisgarria den arren.
.local amaitzen den izen bat normalean tokiko estekan multicast DNS bidez ebazten da, RFC 6762k deskribatzen duen bezala. Multicast-ak ez du bideratutako tunel bat zeharkatzen zerbait nahita zubiratu edo proxya egin ezean, beraz izena segmentua uzten duzun unean uzten du ebazten.
Konpainiaren izen erabat kualifikatua erakundearen resolver-ek zerbitzatzen duten barne-zona bati dagokio. Hori urrunetik funtzionatzen du VPNak resolver horiek bultzatzen dituenean eta bezeroa horiek erabiltzeko konfiguratuta dagoenean. Eta localhost erabilera berezikoa da RFC 6761en arabera: zure aurrean dagoen makinari egiten dio erreferentzia, inoiz ez urruneko zerbitzu bati.
Irakurri resolver-a bidea aldatu aurretik
Galdetu zein izen-zerbitzarik erantzun zuen eta zein atzizki gehitu zen. Kontsulta bera resolver desberdinen bidez erantzun desberdinak ematen ditu, eta desberdintasun hori behar duzun froga da.
getent hosts fileserver getent hosts fileserver.corp.example.com nslookup fileserver.corp.example.com dig +search fileserver A resolvectl query fileserver.corp.example.com scutil --dns | head -30
Kualifikatutako kontsulta ebazten bada baina laburra ez, hutsa atzizkian dago, ez zerbitzarian. Bat ere ebazten ez bada eta helbideak funtzionatzen badu, bezeroak ez du barne-resolver-a batere erabiltzen. Alderatu resolver-zerrenda VPNak bultzatu behar duenarekin, kontsulta bakoitzerako bere tokiko resolver-a gordetzen duen bezeroak ez baitu inoiz barne-zona ikusiko.
Ekarri izen zuzena bezeroarengana
Eskatu administratzaileari urruneko sarbidearen dokumentatutako izena, osorik, eta erabili profilan atzizkiak asmatu beharrean. Hedapenak split DNS onartzen badu, konfiguratu barne-domeinua barne-zerbitzariek ebazteko, gainerako guztiak tokiko resolver-a mantenduz. Bultzatu bilaketa-domeinua VPN konfigurazioaren bidez bezeroak onartzen duen lekuan.
Egiaztatu emaitza bezeroan, ez gatewayean. Zerbitzarian aplikatutako eta bezeroarengana inoiz iristen ez den ezarpen batek ez du ezer aldatzen.
Mantendu ziurtagiriaren identitatea ukitu gabe
Ziurtagiriaren errorea alde batera uzten duen helbidearen gaineko proba batek socket-a ireki zela baino ez du frogatzen. Zerbitzuaren ziurtagiria izen baterako jaulkitzen da, eta bezeroak desadostasuna baztertzen jarraituko du arrazoi ona duelako. Ziurtagiriak barne-izena soilik zerrendatzen badu, erabili izen hori eta konpondu ebazpena, edo lortu erabili nahi duzun helbidea hartzen duen ziurtagiri bat.
Erregistratu konexio arrakastatsua sortu zuten izena, resolver-a eta atzizkia. Erregistro horrek hurrengo pertsonari aurreztuko dio arazo erreala ezkutatzen duen helbidearen gaineko irtenbide zaharra errepikatzea.