Dividita DNS per OpenVPN: kion vojiga domajno devas fari en ĉiu operaciumo

Ĉiu peto pri dividita DNS komenciĝas per la sama frazo: nomoj de la firmao iras al la firmaa DNS, ĉio alia daŭre funkcias. Transformi tiun frazon en agordon signifas respondi tri demandojn por ĉiu operaciumo, kaj la respondoj uzas malsamajn mekanismojn en ĉiu. Profiloj, kiuj funkcias sur Linux-tekkomputilo, ofte fiaskas sur Windows pro kialoj tute ne ligitaj al la tunelo. La breĉo kutime estas agordo de solvilo konfuzita kun itinero.

Unue nomu la politikon, poste elektu la platforman primitivon, kiu esprimas ĝin.

Tri agordoj facile konfuzeblaj

Serĉa sufikso etendas mallongan nomon: tajpi files faras files.corp.example, kiam la solvilo provas sufiksojn laŭvice. Vojiga domajno elektas, kiu solvilo respondas demandojn ene de nomspaco. IP-itinero nur igas la elektitan solvilon atingebla. Tiuj tri vivas en malsamaj tavoloj, kaj anstataŭigi unu per la alia produktas agordon, kiu ŝajnas ĝusta kaj solvas nenion.

La konfuzo havas prezon: aldoni serĉan sufikon sendas ĉiun mallongan nomon al la labora solvilo, inkluzive nomojn apartenantajn aliloke. Elekti vojigan domajnon lasas nerilatajn demandojn ĉe la loka solvilo dum ankoraŭ sendas *.corp.example tra la tunelo.

Linux: nur-itinera domajno, ne serĉa sufikso

En systemd-resolved, domajno kun tildo antaŭe estas nur-itinera domajno, kio signifas, ke demandoj por tiu nomspaco iras al la ligita solvilo sen ankaŭ iĝi serĉa sufikso. resolvectl domain tun0 '~corp.example' tion agordas, kaj resolvectl dns tun0 10.8.0.1 nomas la servilon. Ambaŭ agordoj apartenas al la interfaco, do ili malaperas kun ĝi. La tildo estas la parto, kiun homoj forlasas, kaj sen ĝi mallongaj nomoj komencas solviĝi per la labora solvilo.

Ne instaligu ankaŭ la saman domajnon kiel tutmondan serĉan sufikon. La du agordoj ne estas redundaj; unu enkursigas kaj la alia reskribas tion, kion vi tajpis.

Windows bezonas nomspacan politikon, ne sufikon

Windows tenas la dividitan DNS-politikon en la Name Resolution Policy Table, ne en la DNS-sufikso de la adaptilo. Regulo mapigas nomspacon al specifaj serviloj: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. Agordi nur la sufikon ŝanĝas la aspekton de mallongaj nomoj; ĝi ne direktas la demandon al alia servilo.

Kontrolu la validan politikon per Get-DnsClientNrptPolicy post konektiĝo, ĉar regulo el pli frua konekto povas postvivi la tunelon. Forigu regulojn laŭ nomo, kiam la tunelo falas, kaj tenu la montran nomon stabila, por ke la purigado trafu la ĝustan eron.

Tenu unu posedanton de la solvilo por ĉiu platformo

Labortabla administrilo, OpenVPN up-skripto kaj loka solvila demono ĉiuj povas provi skribi la saman agordon. Kiam ili malkonsentas, venkas la lasta skribanto kaj la rezulto dependas de la malkonstrua ordo. Elektu unu komponanton, kiu posedu la solvilan staton, lasu la aliajn raporti anstataŭ skribi, kaj testu rekonekton: la politiko devus postvivi ĝin sen duobligi regulojn. Testu ankaŭ malkonekton, ĉar restinta stato estas tio, kio igas la sekvan konekton konduti alie.

Aplikoj, kiuj kunportas propran ĉifritan solvilon, tute ignoras la politikon de la operaciumo. Tio estas eco de la aplikaĵo, ne difekto de la tunelo.

Kontrolu la rezulton, ne la profilan tekston

Solvu unu nomon, kiu devas iri tra la tunelo, kaj unu, kiu ne devas, en ĉiu platformo, kaj konfirmu, kiu servilo respondis. resolvectl query host.corp.example kaj Resolve-DnsName host.corp.example ambaŭ raportas la servilon, kiu respondis. Ripetu post rekonekto. Poste konfirmu, ke la solvilo de la tunelo estas atingebla ĉe la adreso, kiun la profilo puŝas, ĉar ĝusta politiko direktita al neatingebla servilo fiaskas same kiel neniu politiko.

Notu la celatan konduton en la notoj de la profilo: kiu sufikso enkursiĝas, kiu servilo respondas ĝin, kaj kio okazas al ĉio alia. La sekva platformo, kiun vi subtenos, bezonos tiun frazon pli ol la agordan dosieron.