Delt DNS og VPN: domenereglar er ikkje IP-ruter

Den berbare datamaskinen din løyser intranet.corp gjennom tunnelen medan gitlab.com held fram til resolvaren til leverandøren, og det er oppsettet som verkar som designa. To separate avgjerder skapte det: ein navnematchregel valde resolvaren, og ei rute bar svaret tilbake. Bryt ein av dei, og nettlesaren viser ein feil som ser lik ut utanfrå. Dei fleste rapportar om delt DNS skildrar den andre feilen medan dei siterer prov om den første.

Dei to helftene bur på ulike stader og blir vanlegvis redigerte av ulike folk. Den eine er DNS-policy knytt til VPN-profilen, den andre er ei rute som tunnelen installerer eller held tilbake. Feilsøkinga stoppar når ingen slår fast kva helft som faktisk flytta seg.

To avgjerder gøymde i éin førespurnad

Navnehelfta er eit policyobjekt, ikkje ei rute. På Windows er det ein navneoppløysingspolicy på VPN-profilen; på Apple-plattformer eit sett matchdomene på eit DNS-innstillingsobjekt; på Linux eit rutingsdomene, ei delt resolverlinje eller rekkjefølgja til navnetenestebrytaren. Stihelfta er vanleg ruting, installert av tunnelen eller for hand, og ho anar ikkje kva eit vertsnavn er. Ein profil som tillèt eit suffiks avgjer berre kven som svarar; han gjer aldri svaret tilgjengeleg.

Ein rask symptomatest skil dei: byt ut namnet med ein adresse. Verkar adressa, er stien i orden og regelen feil. Feilar adressa òg, kan regelen vere riktig og stien mangla.

Korleis kvar plattform uttrykkjer den same navneregelen

Hensikta er identisk, og feltnamna er det ikkje. Eit døme kopiert frå ein klient til ein annan blir parsa reint og treff aldri. Dei tre formene ser slik ut:

Eit match- eller rutingsdomene er ein suffikstest, så intranet.corp dekkjer git.intranet.corp og dekkjer ikkje corp.intranet, og å snu det er den vanlegaste feilen i heile oppsettet. Windows ber mappinga som ein navneoppløysingspolicy knytt til profilen, med si eiga prioritetsrekkjefølgje mot kva som helst suffiksliste grensesnittet alt hadde. Apple-plattformer knyter matchdomene til DNS-innstillingsobjektet til nettverksutvidinga, og systemet brukar dei per avgrensa resolver. Ingen av desse formene er ei rute, og ingen kan gjere ei utilgjengeleg adresse tilgjengeleg. Referansen Windows-navneoppløysingspolicy listar feltnamna og prioritetsreglane for den plattforma, og dei er ikkje dei Apple- eller systemd-dokumenta brukar.

Eit riktig svar treng framleis ein sti

Eit resolver-svar er berre ei adresse, og applikasjonen må framleis nå henne. Eit delt tunneltdesign skyv ofte 10.20.0.0/16 og held tilbake standardruta, så det interne namnet blir løyst og sambandet heng etterpå. Det motsette tilfellet er like vanleg: ruta finst, ein offentleg resolver svarar det private namnet med NXDOMAIN, og feilen blir registrert som eit rutingsproblem. Å teste stien først får deg til å stire på ruter for eit namn som aldri ville blitt løyst.

Det finst òg ein tredje port som ingen av helftene dekkjer. Ein ACL på gatewayen, ein brannmurregel eller ein klientsidepolicy kan sleppe sambandet etter at båe avgjerdene var riktige. Når namnet blir løyst, ruta finst og sambandet framleis går ut på tid, slutt å teste DNS.

Teste namn og stiar i ein fast rekkjefølgje

Vel ein rekkjefølgje og hald deg til han, elles jagar du trinnet som feila sist. Løys det dokumenterte fulle interne namnet, stadfest at svaret er ei adresse rutetabellen kan bere, og gjer det så om att med eit offentleg namn for å prove at tunnelen ikkje fanga alt. På ein systemd-vert er spørjinga og rutingsdomenet til resolvaren éin kommando frå kvarandre:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Ein Windows-klient stiller dei same to spørsmåla med andre cmdlet-ar. Den andre rapporterer grensesnittet systemet faktisk ville brukt:

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

Viss oppslaget returnerer ei adresse og stikontrollen nemner det fysiske grensesnittet, verka navneregelen og ruta ikkje. Viss det korte namnet feilar medan det fulle namnet blir løyst, er suffikslista feil og ikkje resolvaren.

Kvar samanlikninga vanlegvis går gale

Den første feilen er å spørje ein urelatert offentleg resolver om eit privat namn og lese avvisinga som prov om VPN-en. Den andre er å gå ut frå at eit fungerande offentleg oppslag provar resolverstien til tunnelen. Den tredje er å handsame delt tunellering og delt DNS som éi designavgjerd, når ei utrulling kan vere riktig i det eine og øydelagd i det andre. Kvar feil gir sjølvsikre konklusjonar frå ein test som aldri øvde på delen som får skulda.

Ein nettlesar med sin eigen trygge DNS kan òg omgå systemregelen, og difor er det ikkje ei motsetning at éin nettlesar feilar medan ein annan lukkast. Samanlikn resolvaren som svara, ikkje nettlesaren som klaga.

Når båe helftene er synlege, er det gjenverande spørsmålet eit policyspørsmål og ikkje eit teknisk: kva navnerom høyrer til organisasjonen, kven eig kvart svar, og kva av dei som burde forlate maskina i det heile. Skriv det ned ved sida av profilen, for den neste som rører regelen vil trenge det.