Opdelt DNS og VPN: domæneregler er ikke IP-ruter

Din bærbare computer opløser intranet.corp gennem tunnelen, mens gitlab.com fortsat går til udbyderens resolver, og det er den ordning, der virker som designet. To separate beslutninger skabte den: en navnematchningsregel valgte resolveren, og en rute bar svaret tilbage. Bryd en af dem, og browseren viser en fejl, der ser ens ud udefra. De fleste rapporter om opdelt DNS beskriver den anden fejl, mens de citerer beviser om den første.

De to halvdele bor forskellige steder og redigeres normalt af forskellige mennesker. Den ene er DNS-politik knyttet til VPN-profilen, den anden er en rute, som tunnelen installerer eller tilbageholder. Fejlfinding går i stå, når ingen fastslår, hvilken halvdel der faktisk flyttede sig.

To beslutninger skjult i én anmodning

Navnehalvdelen er et politikobjekt, ikke en rute. På Windows er det en navneopløsningspolitik på VPN-profilen; på Apple-platforme et sæt matchdomæner på et DNS-indstillingsobjekt; på Linux et routingdomæne, en linje med opdelt resolver eller rækkefølgen for navnetjenesteskift. Stihalvdelen er almindelig routing, installeret af tunnelen eller manuelt, og den aner ikke, hvad et værtsnavn er. En profil, der tillader et suffiks, bestemmer kun, hvem der svarer; den gør aldrig svaret tilgængeligt.

En hurtig symptomtest skiller dem: erstat navnet med en adresse. Virker adressen, er stien i orden, og reglen er forkert. Fejler adressen også, kan reglen være rigtig, og stien mangle.

Hvordan hver platform udtrykker den samme navneregel

Hensigten er identisk, og feltnavnene er det ikke. Et eksempel kopieret fra en klient til en anden parses pænt og matcher aldrig. De tre former ser sådan ud:

Et match- eller routingdomæne er en suffikstest, så intranet.corp dækker git.intranet.corp og dækker ikke corp.intranet, og at vende det om er den mest almindelige fejl i hele opsætningen. Windows bærer mappingen som en navneopløsningspolitik knyttet til profilen med sin egen prioritetsrækkefølge over for den suffiksliste, grænsefladen allerede havde. Apple-platforme knytter matchdomæner til netværksudvidelsens DNS-indstillingsobjekt, og systemet anvender dem for hver afgrænset resolver. Ingen af disse former er en rute, og ingen af dem kan gøre en utilgængelig adresse tilgængelig. Referencen Windows-navneopløsningspolitik lister feltnavnene og prioritetsreglerne for den platform, og de er ikke dem, Apple- eller systemd-dokumenterne bruger.

Et korrekt svar har stadig brug for en sti

Et resolver-svar er kun en adresse, og applikationen skal stadig nå den. Et opdelt tunneldesign skubber ofte 10.20.0.0/16 og tilbageholder standardruten, så det interne navn opløses, og forbindelsen hænger derefter. Det modsatte tilfælde er lige så almindeligt: ruten findes, en offentlig resolver svarer det private navn med NXDOMAIN, og fejlen registreres som et routingproblem. At teste stien først får dig til at stirre på ruter for et navn, der aldrig ville blive opløst.

Der er også en tredje port, som ingen af halvdelene dækker. En ACL på gatewayen, en firewallregel eller en klientpolitik kan droppe forbindelsen, efter at begge beslutninger var rigtige. Når navnet opløses, ruten findes, og forbindelsen stadig udløber, skal du stoppe med at teste DNS.

Test navne og stier i en fast rækkefølge

Vælg en rækkefølge og hold den, ellers jager du det trin, der fejlede sidst. Opløs det dokumenterede fulde interne navn, bekræft, at svaret er en adresse, routingtabellen kan bære, og gentag derefter med et offentligt navn for at bevise, at tunnelen ikke fangede alt. På en systemd-vært er forespørgslen og resolverens routingdomæne én kommando fra hinanden:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

En Windows-klient stiller de samme to spørgsmål med andre cmdlets. Den anden rapporterer den grænseflade, systemet faktisk ville bruge:

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

Hvis opslaget returnerer en adresse, og stitjekket navngiver den fysiske grænseflade, virkede navnereglen, og ruten gjorde ikke. Hvis det korte navn fejler, mens det fulde navn opløses, er suffikslisten forkert og ikke resolveren.

Hvor sammenligningen normalt går galt

Den første fejl er at spørge en ikke-relateret offentlig resolver om et privat navn og læse afvisningen som bevis om VPN-Forbindelsen. Den anden er at antage, at et fungerende offentligt opslag beviser tunnelens resolversti. Den tredje er at behandle opdelt tunneling og opdelt DNS som én designbeslutning, når en udrulning kan være korrekt i det ene og brudt i det andet. Hver fejl giver selvsikre konklusioner ud fra en test, der aldrig øvede den del, der gives skylden.

En browser med sin egen sikre DNS kan også omgå systemreglen, og derfor er det ikke en modsætning, at én browser fejler, mens en anden lykkes. Sammenlign resolveren, der svarede, ikke browseren, der klagede.

Når begge halvdele er synlige, er det resterende spørgsmål et politikspørgsmål og ikke et teknisk: hvilke navnerum tilhører organisationen, hvem ejer hvert svar, og hvilke af dem skal overhovedet forlade maskinen. Skriv det ned ved siden af profilen, for den næste, der rører reglen, får brug for det.