Delad DNS och VPN: domänregler är inte IP-rutter

Din bärbara dator löser intranet.corp genom tunneln medan gitlab.com fortsätter till leverantörens resolver, och det är uppsättningen som fungerar som designad. Två separata beslut skapade den: en namnmatchningsregel valde resolvern, och en rutt bar tillbaka svaret. Bryt en av dem och webbläsaren visar ett fel som ser likadant ut utifrån. De flesta rapporter om delad DNS beskriver det andra felet medan de citerar bevis om det första.

De två halvorna bor på olika ställen och redigeras oftast av olika personer. Den ena är DNS-policy kopplad till VPN-profilen, den andra är en rutt som tunneln installerar eller håller tillbaka. Felsökningen stannar när ingen fastställer vilken halva som faktiskt flyttade sig.

Två beslut gömda i en förfrågan

Namnhalvan är ett policyobjekt, inte en rutt. I Windows är det en namnmatchande policy på VPN-profilen; på Apple-plattformar en uppsättning matchdomäner på ett DNS-inställningsobjekt; i Linux en routingdomän, en delad resolverrad eller ordningen för namnserviceläget. Sökvägshalvan är vanlig routing, installerad av tunneln eller för hand, och den har ingen aning om vad ett värdnamn är. En profil som tillåter ett suffix avgör bara vem som svarar; den gör aldrig svaret nåbart.

Ett snabbt symptomtest skiljer dem: byt ut namnet mot en adress. Fungerar adressen är sökvägen i ordning och regeln fel. Misslyckas adressen också kan regeln vara rätt och sökvägen saknas.

Hur varje plattform uttrycker samma namnregel

Avsikten är identisk och fältnamnen är det inte. Ett exempel kopierat från en klient till en annan parsas rent och matchar aldrig. De tre formerna ser ut så här:

En match- eller routingdomän är ett suffixtest, så intranet.corp täcker git.intranet.corp och täcker inte corp.intranet, och att vända på det är det vanligaste felet i hela uppsättningen. Windows bär mappningen som en namnmatchande policy kopplad till profilen, med sin egen prioritetsordning mot vilken suffixlista gränssnittet än hade. Apple-plattformar kopplar matchdomäner till DNS-inställningsobjektet för nätverksutökningen, och systemet tillämpar dem per avgränsad resolver. Ingen av dessa former är en rutt, och ingen kan göra en onåbar adress nåbar. Referensen Windows namnmatchande policy listar fältnamnen och prioritetsreglerna för den plattformen, och de är inte de som Apples eller systemds dokument använder.

Ett korrekt svar behöver fortfarande en sökväg

Ett resolver-svar är bara en adress, och programmet måste fortfarande nå den. En delad tunneldesign trycker ofta ut 10.20.0.0/16 och håller tillbaka standardrutten, så det interna namnet löses och anslutningen hänger sedan. Det motsatta fallet är lika vanligt: rutten finns, en offentlig resolver svarar det privata namnet med NXDOMAIN, och felet registreras som ett routingproblem. Att testa sökvägen först får dig att stirra på rutter för ett namn som aldrig skulle lösas.

Det finns också en tredje port som ingen av halvorna täcker. En ACL på gatewayen, en brandväggsregel eller en klientpolicy kan släppa anslutningen efter att båda besluten var riktiga. När namnet löses, rutten finns och anslutningen ändå tar slut på tid, sluta testa DNS.

Testa namn och sökvägar i fast ordning

Välj en ordning och håll dig till den, annars jagar du steget som misslyckades senast. Lös det dokumenterade fullständiga interna namnet, bekräfta att svaret är en adress som routingtabellen kan bära, och upprepa sedan med ett offentligt namn för att bevisa att tunneln inte fångade allt. På en systemd-värd ligger frågan och resolverns routingdomän en kommando från varandra:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

En Windows-klient ställer samma två frågor med andra cmdlets. Den andra rapporterar gränssnittet som systemet faktiskt skulle använda:

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

Om uppslaget returnerar en adress och sökvägskontrollen namnger det fysiska gränssnittet fungerade namnregeln och inte rutten. Om det korta namnet misslyckas medan det fullständiga löses är suffixlistan fel och inte resolvern.

Där jämförelsen vanligen går fel

Det första felet är att fråga en orelaterad offentlig resolver om ett privat namn och läsa avvisningen som bevis om VPN:en. Det andra är att anta att ett fungerande offentligt uppslag bevisar tunnelns resolverväg. Det tredje är att behandla delad tunnling och delad DNS som ett enda designbeslut, när en utrullning kan vara korrekt i det ena och trasig i det andra. Varje fel ger självsäkra slutsatser från ett test som aldrig övade den del som får skulden.

En webbläsare med egen säker DNS kan också kringgå systemregeln, och därför är det ingen motsägelse att en webbläsare misslyckas medan en annan lyckas. Jämför resolvern som svarade, inte webbläsaren som klagade.

När båda halvorna är synliga är den återstående frågan en policyfråga och inte en teknisk: vilka namnrymder som tillhör organisationen, vem som äger varje svar och vilka av dem som alls bör lämna maskinen. Skriv ner det bredvid profilen, för nästa person som rör regeln kommer att behöva det.