Hver opdelt DNS-anmodning begynder med den samme sætning: virksomhedsnavne går til virksomhedens DNS, alt andet bliver ved med at virke. At omsætte den sætning til en konfiguration betyder at besvare tre spørgsmål pr. styresystem, og svarene bruger forskellige mekanismer på hvert af dem. Profiler, der virker på en Linux-bærbar, fejler ofte på Windows af årsager, der intet har med tunnelen at gøre. Kløften er som regel, at en resolverindstilling forveksles med en rute.

Navngiv først politikken, og vælg derefter den platformprimitiv, der udtrykker den.

Tre indstillinger, der er lette at forveksle

Et søgesuffiks udvider et kort navn: at skrive files bliver til files.corp.example, når resolversen prøver suffikser i rækkefølge. Et routingdomæne vælger, hvilken resolver der besvarer forespørgsler inden for et navnerum. En IP-rute gør blot den valgte resolver tilgængelig. De tre lever i forskellige lag, og at bytte det ene ud med det andet giver en konfiguration, der ser rigtig ud og ikke løser noget.

Forvekslingen har en pris: at tilføje et søgesuffiks sender hvert kort navn til arbejdsresolveren, inklusive navne, der hører til et andet sted. At vælge et routingdomæne holder uvedkommende forespørgsler på den lokale resolver, mens *.corp.example stadig sendes gennem tunnelen.

Linux: et kun-routing-domæne, ikke et søgesuffiks

På systemd-resolved er et domæne med en tilde foran et kun-routing-domæne, hvilket betyder, at forespørgsler for det navnerum går til den tilknyttede resolver uden også at blive et søgesuffiks. resolvectl domain tun0 '~corp.example' sætter det, og resolvectl dns tun0 10.8.0.1 navngiver serveren. Begge indstillinger hører til grænsefladen, så de forsvinder med den. Tilden er den del, folk udelader, og uden den begynder korte navne at blive opløst via arbejdsresolveren.

Installer ikke også det samme domæne som globalt søgesuffiks. De to indstillinger er ikke overflødige; den ene ruter, og den anden omskriver det, du skrev.

Windows har brug for en navnerumspolitik, ikke et suffiks

Windows opbevarer opdelt DNS-politik i Name Resolution Policy Table, ikke i adapterens DNS-suffiks. En regel knytter et navnerum til bestemte servere: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. At sætte suffikset alene ændrer, hvordan korte navne ser ud; det sender ikke forespørgslen til en anden server.

Kontrollér den gældende politik med Get-DnsClientNrptPolicy efter forbindelsen, fordi en regel fra en tidligere forbindelse kan overleve tunnelen. Fjern regler ved navn, når tunnelen går ned, og hold visningsnavnet stabilt, så oprydningen rammer den rigtige post.

Hold én resolver-ejer pr. platform

En skrivebordsmanager, et OpenVPN up-script og en lokal resolver-daemon kan alle forsøge at skrive den samme konfiguration. Når de er uenige, vinder den sidste skriver, og resultatet afhænger af nedbrydningsrækkefølgen. Vælg én komponent, der ejer resolverens tilstand, lad de andre rapportere i stedet for at skrive, og test en genopkobling: politikken bør overleve den uden at duplikere regler. Test også en afbrydelse, fordi resttilstand er det, der får den næste forbindelse til at opføre sig anderledes.

Programmer, der leverer deres egen krypterede resolver, ignorerer styresystemets politik helt. Det er en egenskab ved programmet, ikke en fejl i tunnelen.

Verificér resultatet, ikke profiltteksten

Opløs ét navn, der skal gå gennem tunnelen, og ét, der ikke skal, på hver platform, og bekræft, hvilken server der svarede. resolvectl query host.corp.example og Resolve-DnsName host.corp.example rapporterer begge den server, der svarede. Gentag efter en genopkobling. Bekræft derefter, at tunnelens resolver er tilgængelig på den adresse, profilen sender, fordi en korrekt politik, der peger på en utilgængelig server, fejler på samme måde som ingen politik.

Notér den tilsigtede adfærd i profilens noter: hvilket suffiks der rutes, hvilken server der besvarer det, og hvad der sker med alt andet. Den næste platform, du understøtter, får mere brug for den sætning end for konfigurationsfilen.

Relaterede artikler