Gesplitst DNS en VPN: domeinregels zijn geen IP-routes

Uw laptop lost intranet.corp op via de tunnel terwijl gitlab.com naar de resolver van de provider blijft gaan, en dat is de opstelling die werkt zoals ontworpen. Twee afzonderlijke beslissingen brachten haar voort: een naamovereenkomstruletje koos de resolver, en een route droeg het antwoord terug. Breek een van beide en de browser toont een storing die er van buiten hetzelfde uitziet. De meeste rapporten over gesplitst DNS beschrijven de tweede storing terwijl ze bewijs over de eerste aanhalen.

De twee helften leven op verschillende plekken en worden meestal door verschillende mensen bewerkt. De ene is DNS-beleid dat aan het VPN-profiel hangt, de andere is een route die de tunnel installeert of achterhoudt. Foutopsporing stokt wanneer niemand vaststelt welke helft werkelijk is verschoven.

Twee beslissingen verborgen in één verzoek

De naamhelft is een beleidsobject, geen route. Op Windows is het een naamresolutiebeleid op het VPN-profiel; op Apple-platforms een reeks overeenkomende domeinen op een DNS-instellingenobject; op Linux een routeringsdomein, een gesplitste resolverregel of de volgorde van de naamdienstschakelaar. De padhelft is gewone routering, door de tunnel of met de hand geïnstalleerd, en die weet niet wat een hostnaam is. Een profiel dat een suffix toestaat beslist alleen wie antwoordt; het maakt het antwoord nooit bereikbaar.

Een snelle symptoomtest scheidt ze: vervang de naam door een adres. Als het adres werkt, is het pad in orde en de regel fout. Als ook het adres faalt, kan de regel juist zijn en het pad ontbreken.

Hoe elk platform dezelfde naamregel uitdrukt

De bedoeling is identiek en de veldnamen niet. Een voorbeeld dat van de ene client naar de andere is gekopieerd, wordt netjes geparsed en komt nooit overeen. De drie vormen zien er zo uit:

Een overeenkomend of routeringsdomein is een suffixtest, dus intranet.corp dekt git.intranet.corp en dekt corp.intranet niet, en dat omdraaien is de meest voorkomende fout in de hele opstelling. Windows draagt de mapping als naamresolutiebeleid dat aan het profiel hangt, met een eigen prioriteitsvolgorde tegenover welke suffixlijst de interface al had. Apple-platforms koppelen overeenkomende domeinen aan het DNS-instellingenobject van de netwerkextensie, en het systeem past ze per afgebakende resolver toe. Geen van deze vormen is een route, en geen ervan kan een onbereikbaar adres bereikbaar maken. De referentie naamresolutiebeleid van Windows somt de veldnamen en prioriteitsregels voor dat platform op, en het zijn niet die van de Apple- of systemd-documentatie.

Een juist antwoord heeft nog steeds een pad nodig

Een resolverantwoord is alleen een adres, en de toepassing moet het nog steeds bereiken. Een gesplitst-tunnelontwerp duwt vaak 10.20.0.0/16 en houdt de standaardroute tegen, zodat de interne naam wordt opgelost en de verbinding daarna blijft hangen. Het omgekeerde geval komt even vaak voor: de route bestaat, een openbare resolver antwoordt de privénaam met NXDOMAIN, en de storing wordt als routeringsprobleem geboekt. Eerst het pad testen laat u naar routes staren voor een naam die nooit opgelost zou worden.

Er is ook een derde poort die geen van beide helften dekt. Een ACL op de gateway, een firewallregel of een beleid aan de clientkant kan de verbinding laten vallen nadat beide beslissingen juist waren. Als de naam oplost, de route bestaat en de verbinding toch verloopt, stop dan met DNS testen.

Namen en paden in een vaste volgorde testen

Kies een volgorde en houd die aan, anders jaagt u op de stap die het laatst faalde. Los de gedocumenteerde volledige interne naam op, bevestig dat het antwoord een adres is dat de routetabel kan dragen, en herhaal dan met een openbare naam om te bewijzen dat de tunnel niet alles heeft gevangen. Op een systemd-host liggen de query en het routeringsdomein van de resolver één opdracht uit elkaar:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Een Windows-client stelt dezelfde twee vragen met andere cmdlets. De tweede meldt de interface die het systeem werkelijk zou gebruiken:

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

Als de opzoeking een adres teruggeeft en de padcontrole de fysieke interface noemt, werkte de naamregel en de route niet. Als de korte naam faalt terwijl de volledige naam oplost, is de suffixlijst fout en niet de resolver.

Waar de vergelijking meestal misgaat

De eerste fout is een niet-verwante openbare resolver naar een privénaam vragen en de weigering lezen als bewijs over de VPN. De tweede is aannemen dat een werkende openbare opzoeking het resolverpad van de tunnel bewijst. De derde is gesplitst tunnelen en gesplitst DNS als één ontwerpbeslissing behandelen, terwijl een uitrol in het ene juist en in het andere kapot kan zijn. Elke fout levert zelfverzekerde conclusies op uit een test die het beschuldigde deel nooit heeft geoefend.

Een browser met eigen beveiligde DNS kan de systeemregel ook omzeilen, daarom is het geen tegenspraak dat de ene browser faalt terwijl de andere slaagt. Vergelijk de resolver die antwoordde, niet de browser die klaagde.

Zodra beide helften zichtbaar zijn, is de resterende vraag een beleidsvraag en geen technische: welke naamruimten bij de organisatie horen, wie elk antwoord bezit en welke ervan de machine helemaal zouden moeten verlaten. Schrijf dat naast het profiel, want de volgende persoon die de regel aanraakt heeft het nodig.