Gesplitste DNS over OpenVPN: wat een routeringsdomein op elk besturingssysteem moet doen
Een zoeksuffix, een routeringsdomein en een IP-route zijn drie verschillende dingen. Stel het beleid per platform in en bewijs daarna welke server de query heeft beantwoord.
Elk gesplitst DNS-verzoek begint met dezelfde zin: bedrijfsnamen gaan naar de bedrijfs-DNS, al het andere blijft werken. Die zin omzetten in een configuratie betekent per besturingssysteem drie vragen beantwoorden, en de antwoorden gebruiken op elk daarvan andere mechanismen. Profielen die op een Linux-laptop werken, falen vaak op Windows om redenen die niets met de tunnel te maken hebben. Het verschil is meestal een resolverinstelling die voor een route wordt aangezien.
Noem eerst het beleid en kies dan het platformprimitief dat het uitdrukt.
Drie instellingen die makkelijk te verwarren zijn
Een zoeksuffix breidt een korte naam uit: files typen wordt files.corp.example wanneer de resolver de suffixen op volgorde probeert. Een routeringsdomein kiest welke resolver vragen binnen een naamruimte beantwoordt. Een IP-route maakt alleen de gekozen resolver bereikbaar. Die drie leven in verschillende lagen, en het ene door het andere vervangen levert een configuratie op die er goed uitziet en niets oplost.
De verwarring heeft een prijs: een zoeksuffix toevoegen stuurt elke korte naam naar de werkresolver, inclusief namen die elders thuishoren. Een routeringsdomein kiezen houdt ongerelateerde vragen bij de lokale resolver en stuurt *.corp.example toch door de tunnel.
Linux: een zuiver routeringsdomein, geen zoeksuffix
Op systemd-resolved is een domein met een tilde ervoor een zuiver routeringsdomein, wat betekent dat vragen voor die naamruimte naar de gekoppelde resolver gaan zonder ook een zoeksuffix te worden. resolvectl domain tun0 '~corp.example' stelt dat in, en resolvectl dns tun0 10.8.0.1 benoemt de server. Beide instellingen horen bij de interface, dus ze verdwijnen ermee. De tilde is het deel dat mensen overslaan, en zonder die begint korte namen via de werkresolver op te lossen.
Installeer hetzelfde domein ook niet als globaal zoeksuffix. De twee instellingen zijn niet overbodig; de ene routeert en de andere herschrijft wat je hebt getypt.
Windows heeft een naamruimtebeleid nodig, geen suffix
Windows bewaart gesplitst DNS-beleid in de Name Resolution Policy Table, niet in het DNS-suffix van de adapter. Een regel koppelt een naamruimte aan specifieke servers: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. Alleen het suffix instellen verandert hoe korte namen eruitzien; het stuurt de vraag niet naar een andere server.
Controleer het effectieve beleid met Get-DnsClientNrptPolicy na het verbinden, want een regel van een eerdere verbinding kan de tunnel overleven. Verwijder regels op naam wanneer de tunnel wegvalt, en houd de weergavenaam stabiel zodat de opruiming de juiste vermelding raakt.
Eén resolvereigenaar per platform
Een bureaubladbeheerder, een OpenVPN up-script en een lokale resolver-daemon kunnen allemaal proberen dezelfde configuratie te schrijven. Als ze het oneens zijn, wint de laatste schrijver en het resultaat hangt af van de volgorde van afbreken. Kies één component die de resolvertoestand bezit, laat de anderen rapporteren in plaats van schrijven, en test een herverbinding: het beleid moet die overleven zonder regels te dupliceren. Test ook een verbreking, want het is de achtergebleven toestand die de volgende verbinding anders laat werken.
Applicaties die hun eigen versleutelde resolver meebrengen, negeren het beleid van het besturingssysteem volledig. Dat is een eigenschap van de applicatie, geen defect in de tunnel.
Controleer het resultaat, niet de tekst van het profiel
Los één naam op die door de tunnel moet en één die niet moet, op elk platform, en bevestig welke server heeft geantwoord. resolvectl query host.corp.example en Resolve-DnsName host.corp.example rapporteren beide de server die reageerde. Herhaal na een herverbinding. Bevestig daarna dat de resolver van de tunnel bereikbaar is op het adres dat het profiel pusht, want een correct beleid dat naar een onbereikbare server wijst, faalt hetzelfde als helemaal geen beleid.
Leg het bedoelde gedrag vast in de notities van het profiel: welk suffix routeert, welke server daarop antwoordt en wat er met al het andere gebeurt. Het volgende platform dat je ondersteunt, heeft die zin meer nodig dan het configuratiebestand.