Delt DNS over OpenVPN: hva et rutingsdomene må gjøre på hvert operativsystem
Et søketillegg, et rutingsdomene og en IP-rute er tre forskjellige ting. Sett policyen per plattform, og bevis deretter hvilken server som svarte på spørringen.
Hver delt DNS-forespørsel begynner med samme setning: selskapets navn går til selskapets DNS, alt annet fortsetter å virke. Å gjøre den setningen om til en konfigurasjon betyr å svare på tre spørsmål per operativsystem, og svarene bruker forskjellige mekanismer på hvert av dem. Profiler som virker på en Linux-bærbar, feiler ofte på Windows av grunner som ikke har noe med tunnelen å gjøre. Gapet er vanligvis en resolverinnstilling som er tatt for en rute.
Navngi policyen først, og velg deretter plattformprimitiven som uttrykker den.
Tre innstillinger som er lette å forveksle
Et søketillegg utvider et kort navn: å skrive files blir files.corp.example når resolveren prøver tilleggene i rekkefølge. Et rutingsdomene velger hvilken resolver som svarer på forespørsler innenfor et navnerom. En IP-rute gjør bare den valgte resolveren tilgjengelig. Disse tre lever i forskjellige lag, og å bytte ett mot et annet gir en konfigurasjon som ser riktig ut og ikke løser noe.
Forvirringen har en pris: å legge til et søketillegg sender hvert kortnavn til arbeidsresolveren, også navn som hører hjemme andre steder. Å velge et rutingsdomene holder urelaterte forespørsler på den lokale resolveren og sender likevel *.corp.example gjennom tunnelen.
Linux: et rent rutingsdomene, ikke et søketillegg
På systemd-resolved er et domene med tilde foran et rent rutingsdomene, noe som betyr at forespørsler for det navnerommet går til den tilknyttede resolveren uten også å bli et søketillegg. resolvectl domain tun0 '~corp.example' setter dette, og resolvectl dns tun0 10.8.0.1 navngir serveren. Begge innstillingene tilhører grensesnittet, så de forsvinner sammen med det. Tilden er den delen folk utelater, og uten den begynner kortnavn å løses gjennom arbeidsresolveren.
Ikke installer det samme domenet også som et globalt søketillegg. De to innstillingene er ikke overflødige; den ene ruter og den andre skriver om det du skrev.
Windows trenger en navneromspolicy, ikke et tillegg
Windows oppbevarer delt DNS-policy i Name Resolution Policy Table, ikke i adapterens DNS-tillegg. En regel knytter et navnerom til bestemte servere: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. Å sette bare tillegget endrer hvordan kortnavn ser ut; det sender ikke forespørselen til en annen server.
Kontroller den effektive policyen med Get-DnsClientNrptPolicy etter tilkobling, fordi en regel fra en tidligere tilkobling kan overleve tunnelen. Fjern regler ved navn når tunnelen faller, og hold visningsnavnet stabilt slik at oppryddingen treffer riktig oppføring.
Én resolvereier per plattform
En skrivebordsbehandler, et OpenVPN up-skript og en lokal resolverdaemon kan alle prøve å skrive den samme konfigurasjonen. Når de er uenige, vinner den siste skriveren, og resultatet avhenger av rekkefølgen ved nedriving. Velg én komponent som eier resolverens tilstand, la de andre rapportere i stedet for å skrive, og test en gjenoppkobling: policyen bør overleve den uten å duplisere regler. Test også en frakobling, fordi det er den gjenværende tilstanden som får den neste tilkoblingen til å oppføre seg annerledes.
Applikasjoner som har sin egen krypterte resolver, ignorerer operativsystemets policy helt. Det er en egenskap ved applikasjonen, ikke en feil i tunnelen.
Kontroller resultatet, ikke profilteksten
Løs ett navn som skal gjennom tunnelen og ett som ikke skal, på hver plattform, og bekreft hvilken server som svarte. resolvectl query host.corp.example og Resolve-DnsName host.corp.example rapporterer begge serveren som svarte. Gjenta etter en gjenoppkobling. Bekreft deretter at tunnelens resolver er tilgjengelig på adressen profilen sender, fordi en riktig policy som peker på en utilgjengelig server, feiler på samme måte som ingen policy i det hele tatt.
Registrer den tiltenkte oppførselen i profilens notater: hvilket tillegg som ruter, hvilken server som svarer på det, og hva som skjer med alt annet. Den neste plattformen du støtter, trenger den setningen mer enn konfigurasjonsfilen.