Zein estekak erantzuten du: bideratze-domeinuak split-tunnel VPN DNSrako

Eduki ohiko nabigazioa esteka lokalean, enpresaren izenak tunelek ematen duen DNS zerbitzariaren bidez ebazten diren bitartean. VPNaren bide lehenetsia desaktibatzeak lehen erdia ematen dizu eta bigarrena eraiki gabe uzten du. Hona hemen falta den ezarpena, haren esanahia aldatzen duen puntuazioa eta zein esteka erantzun zuen benetan erakusten duen komando bakarra. NetworkManager eta systemd-resolved suposatzen dira testu osoan, bikote hori baita nahasmena normalean hasten den tokia.

Lehen urratsa: bereizi bidea ebazletik

ipv4.never-default bideratze-galdera bati erantzuten dio, NetworkManageri konexio hau IPv4 trafiko guztiaren bide gisa instalatzea eragozten baitio. DNS bideratze-domeinu batek beste galdera bati erantzuten dio: zein estekaren izen-zerbitzarik jasotzen duen atzizki bat datozen kontsulta. Batek ez du bestea inplikatzen, eta profilek bat eraman dezake urteetan zehar bestea falta zaion bitartean. Bide soilak esan nahi du tunelek enpresaren azpisareak daramatzala eta haren ebazleak enpresaren izenei erantzuten diela, beste guztia ukitu gabe utzita.

Ezarri bidearen propietatea soilik eta barne-izenek huts egiten dute, normalean tunele hautsi bat bezala entzuten den denbora-mugarekin. Ezarri domeinua soilik eta isilpean bilaketa-atzizki bat gehitu diezu makinako izen labur guztiei. Bi erroreek txartela VPN zerbitzarira bidaltzen dute, eta hori gutxitan da oker dagoen zatia.

Bigarren urratsa: gehitu bideratze-soiliko domeinu bat profilean

Demagun konexioak corp-vpn duela izena, enpresaren atzizkia internal.example dela eta tunelaren ebazlea jada irisgarria dela. Irakurri lehenengo uneko balioak, beheko komandoek jada sarrerak izan ditzaketen propietateak aldatzen baitituzte.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Ordeztu zeure konexio-izenarekin eta atzizkiarekin, goiko balioak adierazgarriak baitira. Plus zeinuak dirudiena baino garrantzi handiagoa du: harekin balioa lehendik dagoen zerrendari gehitzen zaio, eta gabe propietatea ordeztu egiten da eta erlaziorik gabeko domeinuak desagertzen dira atzo funtzionatzen zuen profiletik. Tildak portaera aldatzen du, ez estiloa, eta beheko paragrafoak zer hautatzen duen azaltzen du. Mantendu irakurketa idazketaren aurretik, ordezkapen-formak inoiz harritu ez zaitzan.

Hasierako tildak bideratze-soiliko domeinu bat markatzen du, beraz bat datozen kontsultak esteka honen zerbitzarietara joaten dira eta atzizkia ez zaie izen laburrei gehitzen. Kendu tilda eta kate berbera bilaketa-atzizki ere bihurtzen da, jendeak gutxitan nahi duen emaitza desberdina. Goiko bi ezarpenak IPv4 dira, beraz pila bikoitzeko profilek ipv6.never-default eta bideratze-domeinu bera behar ditu ipv6.dns-search-en, bestela IPv6 aldeak bide lehenetsia erabiltzen jarraitzen du eta barne-izenek han huts egiten dute.

Hirugarren urratsa: galdetu resolvectl-i zein esteka erantzun zuen

Exekutatu resolvectl status eta irakurri esteka bakoitzaren DNS zerbitzariak eta domeinuak, gero exekutatu resolvectl query host.internal.example kontsultatzea baimenduta duzun benetako barne-izen baten aurka. Bigarren komandoa da bideratze-domeinuak bere lana egiten duen froga zuzen bakarra, erantzun zuen esteka izendatzen baitu. Egoera-zerrenda soil batek konfigurazioa frogatzen du; kontsultak ebazpena frogatzen du.

systemd-resolvedek ondoen bat datorren bideratze-domeinua hautatzen du, beraz beste esteka bateko domeinu zehatzago batek lasterketa irabaz dezake oraindik. Kontsulta espero ez zenuen esteka batetik badator, irakurri domeinu-zerrendak VPNaren DNS zerbitzaria ukitu aurretik. ~. erro-domeinuak denarekin bat egiten du, eta jada badago, zure domeinu zehatzak bere izenetarako irabazten du oraindik, estekak eskatu zenuena baino askoz gehiagori erantzuten dion bitartean. Kendu edo estu ezazu erro-sarrera hori asmoa enpresaren izenak soilik zirenean.

VPNaren estekak DNS zerbitzaririk bat ere zerrendatzen ez badu, bezeroak ez zuen inoiz bat erregistratu. Atzean zerbitzaririk gabeko bideratze-domeinuak falta den domeinu batek baino modu desberdinean huts egiten du, beraz konpondu lehenengo erregistroa.

Laugarren urratsa: izenak ebazten duenean baina zerbitzuak ez

Erantzun zuzen batek ebazpena funtzionatu zuela frogatzen du soilik, eta aplikazioak jaso zuen helbidera iristeko bidea behar du oraindik. Bide horrek oraintxe konfiguratu duzun bide lehenetsi zatitua gainditu behar du, beraz egiaztatu ezazu DNS berriro errudun egiteko aurretik. Gero egiaztatu irisgarritasuna zerbitzuaren portuan, fitxategi-partekatze edo direktorio-zerbitzu batek ebazpenean, bideratzean edo autentifikazioan huts egiten baitu eta kasu bakoitzean oso antzeko mezuak ematen baititu. Eduki hiru geruza horiek bereizita emaitza jakinaraztean, bestela hurrengo pertsonak jada zuzena zen DNS berrikusten du.

Galdera honen ondoan dabilen Sambaren aldaketak sarbide-geruzari heltzen dio, ez DNS hautapenari. Izen-ebazpen hutsegite bati aplikatzea da arazo txiki batek bigarren bat lortzeko modua.

Bosgarren urratsa: ez ordeztu ebazlea falta den domeinu bat konpontzeko

Ebazlearen fitxategia gainidazten duen edo beste ebazle-kudeatzaile bat instalatzen duen aholkuak beste arazo bat konpontzen du. Sistema-integrazio aldaketak dira, beren hutsegite-moduekin, eta horietako batek ere ez du gehitzen inoiz konfiguratu ez zen bideratze-domeinurik. Zehaztu zein osagaik duen izen-ebazpena makinan ordeztu aurretik, NetworkManager mahaigainean systemd-resolvedekin jabetza hori jada definituta baitago. Haren aurka borrokatzea da funtzionatzen duen ezarpen bat inork erreproduzitu ezin dezakeen zerbait bihurtzeko modua.

Lan-ordena: egiaztatu tunelek ebazle bat ematen duela, gehitu bideratze-soiliko domeinua, konektatu berriro profileko kontrolekin, egiaztatu erantzuten duen esteka, eta gero probatu zerbitzua bere portuan. Segida horrek bigarren elkarrizketarik gabe hurrengo pertsonari eman diezaiokezun emaitza uzten du.