Delt DNS og VPN: domenneregler er ikke IP-ruter

Den bærbare datamaskinen din løser intranet.corp gjennom tunnelen mens gitlab.com fortsatt går til leverandørens resolver, og det er oppsettet som virker som designet. To separate beslutninger skapte det: en navnematchingsregel valgte resolveren, og en rute bar svaret tilbake. Bryt en av dem, og nettleseren viser en feil som ser lik ut utenfra. De fleste rapporter om delt DNS beskriver den andre feilen mens de siterer bevis om den første.

De to halvdelene bor på forskjellige steder og redigeres vanligvis av forskjellige personer. Den ene er DNS-policy knyttet til VPN-profilen, den andre er en rute som tunnelen installerer eller holder tilbake. Feilsøkingen stopper når ingen fastslår hvilken halvdel som faktisk flyttet seg.

To beslutninger skjult i én forespørsel

Navnehalvdelen er et policyobjekt, ikke en rute. På Windows er det en navneoppløsningspolicy på VPN-profilen; på Apple-plattformer et sett matchdomener på et DNS-innstillingsobjekt; på Linux et rutingsdomene, en delt resolverlinje eller rekkefølgen til navnetjenestebryteren. Stihalvdelen er vanlig ruting, installert av tunnelen eller for hånd, og den aner ikke hva et vertsnavn er. En profil som tillater et suffiks bestemmer bare hvem som svarer; den gjør aldri svaret tilgjengelig.

En rask symptomtest skiller dem: bytt ut navnet med en adresse. Virker adressen, er stien i orden og regelen feil. Feiler adressen også, kan regelen være riktig og stien mangle.

Hvordan hver plattform uttrykker den samme navneregelen

Hensikten er identisk, og feltnavnene er det ikke. Et eksempel kopiert fra en klient til en annen parses rent og treffer aldri. De tre formene ser slik ut:

Et match- eller rutingsdomene er en suffikstest, så intranet.corp dekker git.intranet.corp og dekker ikke corp.intranet, og å snu det er den vanligste feilen i hele oppsettet. Windows bærer mappingen som en navneoppløsningspolicy knyttet til profilen, med sin egen prioritetsrekkefølge mot hvilken som helst suffiksliste grensesnittet allerede hadde. Apple-plattformer knytter matchdomener til DNS-innstillingsobjektet til nettverksutvidelsen, og systemet bruker dem per avgrenset resolver. Ingen av disse formene er en rute, og ingen kan gjøre en utilgjengelig adresse tilgjengelig. Referansen Windows-navneoppløsningspolicy lister feltnavnene og prioritetsreglene for den plattformen, og de er ikke de Apple- eller systemd-dokumentene bruker.

Et riktig svar trenger fortsatt en sti

Et resolver-svar er bare en adresse, og applikasjonen må fortsatt nå den. Et delt tunneldesign skyver ofte 10.20.0.0/16 og holder tilbake standardruten, så det interne navnet løses og forbindelsen henger etterpå. Det motsatte tilfellet er like vanlig: ruten finnes, en offentlig resolver svarer det private navnet med NXDOMAIN, og feilen registreres som et rutingsproblem. Å teste stien først får deg til å stirre på ruter for et navn som aldri ville blitt løst.

Det finnes også en tredje port som ingen av halvdelene dekker. En ACL på gatewayen, en brannmurregel eller en klientsidepolicy kan slippe forbindelsen etter at begge beslutningene var riktige. Når navnet løses, ruten finnes og forbindelsen fortsatt går ut på tid, slutt å teste DNS.

Test navn og stier i en fast rekkefølge

Velg en rekkefølge og hold deg til den, ellers jager du trinnet som feilet sist. Løs det dokumenterte fulle interne navnet, bekreft at svaret er en adresse rutetabellen kan bære, og gjenta deretter med et offentlig navn for å bevise at tunnelen ikke fanget alt. På en systemd-vert er spørringen og resolverens rutingsdomene én kommando fra hverandre:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

En Windows-klient stiller de samme to spørsmålene med andre cmdlets. Den andre rapporterer grensesnittet systemet faktisk ville brukt:

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

Hvis oppslaget returnerer en adresse og stikontrollen navngir det fysiske grensesnittet, virket navneregelen og ruten ikke. Hvis det korte navnet feiler mens det fulle navnet løses, er suffikslisten feil og ikke resolveren.

Hvor sammenligningen vanligvis går galt

Den første feilen er å spørre en urelatert offentlig resolver om et privat navn og lese avvisningen som bevis om VPN-en. Den andre er å anta at et fungerende offentlig oppslag beviser tunnelens resolversti. Den tredje er å behandle delt tunellering og delt DNS som én designbeslutning, når en utrulling kan være riktig i det ene og ødelagt i det andre. Hver feil gir selvsikre konklusjoner fra en test som aldri øvde på delen som får skylden.

En nettleser med sin egen sikre DNS kan også omgå systemregelen, og derfor er det ikke en motsetning at én nettleser feiler mens en annen lykkes. Sammenlign resolveren som svarte, ikke nettleseren som klaget.

Når begge halvdelene er synlige, er det gjenværende spørsmålet et policyspørsmål og ikke et teknisk: hvilke navnerom tilhører organisasjonen, hvem eier hvert svar, og hvilke av dem bør forlate maskinen i det hele tatt. Skriv det ned ved siden av profilen, for den neste som rører regelen vil trenge det.