DNS zatitua eta VPN: domeinu-arauak ez dira IP ibilbideak

Zure eramangarriak intranet.corp tuneletik ebazten du, gitlab.com hornitzailearen ebaztzailera joaten jarraitzen duen bitartean, eta hori da diseinatu bezala funtzionatzen duen antolaketa. Bi erabaki independentek sortu zuten: izenak batzeko arau batek ebaztzailea aukeratu zuen, eta ibilbide batek erantzuna ekarri zuen. Edozein hautsi eta arakatzaileak kanpotik berdin ikusten den hutsegitea erakusten du. DNS zatituaren txostenen gehiengoak bigarren hutsegitea deskribatzen du, lehenengoari buruzko frogak aipatzen dituen bitartean.

Bi erdiak leku desberdinetan bizi dira eta normalean pertsona desberdinek editatzen dituzte. Bata VPN profilean erantsitako DNS politika da, bestea tunelak instalatzen edo atxikitzen duen ibilbidea. Arazketa gelditu egiten da inork zein erdi mugitu zen zehazten ez duenean.

Eskari bakarrean ezkutuko bi erabaki

Izenaren erdia politika objektua da, ez ibilbidea. Windowsen VPN profileko izen-ebazpen politika da; Apple plataformetan DNS ezarpenen objektuko bat-etortze domeinuen multzoa; Linuxen bideratze domeinua, ebaztzaile zatituaren lerroa edo izen zerbitzuaren etengailuaren ordena. Bidearen erdia bideratze arrunta da, tunelak edo eskuz instalatua, eta ez daki zer den ostalari-izena. Atzizki bat onartzen duen profilek nork erantzuten duen soilik erabakitzen du; ez du inoiz erantzuna eskuragarri egiten.

Sintoma proba azkar batek banatzen ditu: ordezkatu izena helbide batekin. Helbidea funtzionatzen badu, bidea ondo dago eta araua oker. Helbideak ere huts egiten badu, araua zuzena izan daiteke eta bidea falta.

Nola adierazten duen plataforma bakoitzak izen-arau bera

Asmoa berbera da eta eremuen izenak ez. Bezero batetik bestera kopiatutako adibide bat garbi analizatzen da eta ez dator inoiz bat. Hiru formak honela ikusten dira:

Bat-etortze edo bideratze domeinu bat atzizki proba da, beraz intranet.corp-ek git.intranet.corp estaltzen du eta ez du corp.intranet estaltzen, eta hori alderantzikatzea konfigurazio osoko akats ohikoena da. Windowsek mapaketa profilean erantsitako izen-ebazpen politik gisa darama, interfazeak jada zuen atzizki-zerrendaren aurrean duen lehentasun ordenarekin. Apple plataformek bat-etortze domeinuak sare luzapenaren DNS ezarpenen objektuari lotzen dizkiote, eta sistemak ebaztzaile mugatu bakoitzeko aplikatzen ditu. Forma horietako bat ere ez da ibilbide, eta batek ere ezin du helbide eskuragaitza eskuragarri bihurtu. Windows izen-ebazpen politika erreferentziak plataforma horretako eremuen izenak eta lehentasun arauak zerrendatzen ditu, eta ez dira Apple edo systemd dokumentuek erabiltzen dituztenak.

Erantzun zuzen batek oraindik bidea behar du

Ebaztzaile baten erantzuna helbide bat besterik ez da, eta aplikazioak hara iritsi behar du oraindik. Tunel zatituaren diseinuak sarritan 10.20.0.0/16 bultzatzen du eta lehenetsitako ibilbidea atxikitzen du, beraz barne izena ebazten da eta konexioa gero geratzen da. Aurkako kasua bezain ohikoa da: ibilbidea existitzen da, ebaztzaile publiko batek izen pribatuari NXDOMAIN-ekin erantzuten dio, eta hutsegitea bideratze arazo gisa erregistratzen da. Bidea lehenengo probatzeak inoiz ebatziko ez zen izen baten ibilbideak begira uzten zaitu.

Hirugarren ate bat ere badago, inongo erdik estaltzen ez duena. Ateko ACL batek, suebaki arau batek edo bezero aldeko politikak konexioa bota dezakete bi erabakiak zuzenak izan ondoren. Izena ebazten denean, ibilbidea existitzen da eta konexioak oraindik denbora agortzen duenean, utzi DNS probatzeari.

Izenak eta bideak orden finkoan probatzea

Aukeratu orden bat eta eutsi, bestela azkenekoz huts egin zuen pausoaren atzetik ibiliko zara. Ebatzi dokumentatutako barne izen osoa, egiaztatu erantzuna bideratze taulak eraman dezakeen helbidea dela, eta gero errepikatu izen publiko batekin tunelak dena harrapatu ez zuela frogatzeko. systemd ostalari batean kontsulta eta ebaztzailearen bideratze domeinua komando bat dago elkarrengandik:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Windows bezero batek bi galdera berak egiten ditu cmdlet desberdinekin. Bigarrenak sistemak benetan erabiliko lukeen interfazea jakinarazten du:

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

Bilaketak helbide bat itzultzen badu eta bidearen egiaztapenak interfaze fisikoa izendatzen badu, izen-arauak funtzionatu zuen eta ibilbideak ez. Izen laburrak huts egiten badu izen osoa ebazten den bitartean, atzizki-zerrenda dago oker, ez ebaztzailea.

Non okertzen den konparazioa normalean

Lehen akatsa da erlaziorik gabeko ebaztzaile publiko bati izen pribatu bati buruz galdetzea eta ukazioa VPNari buruzko froga gisa irakurtzea. Bigarrena da funtzionatzen duen bilaketa publiko batek tunelaren ebaztzaile bidea frogatzen duela suposatzea. Hirugarrena tunel zatitua eta DNS zatitua diseinu erabaki bakar gisa tratatzea da, hedapen bat batean zuzena eta bestean hautsita egon daitekeenean. Akats bakoitzak ziurtasun handiko ondorioak ematen ditu inoiz salatutako zatia landu ez zuen proba batetik.

Bere DNS segurua duen arakatzaile batek sistema-araua ere saihestu dezake, horregatik arakatzaile batek huts egitea besteak lortzen duen bitartean ez da kontraesan bat. Konparatu erantzun zuen ebaztzailea, ez kexatu zen arakatzailea.

Bi erdiak ikusgai daudenean, geratzen den galdera politika galdera da eta ez teknikoa: zein izen-espazio dagozkion erakundeari, nork duen erantzun bakoitza eta zeinek utzi behar duten makina. Idatzi hori profilearen ondoan, araua ukituko duen hurrengo pertsonak behar izango baitu.