To VPN'er, én resolver: den sidste skribent vinder

To VPN-klienter er forbundet, en til arbejde og en til et laboratorienetværk, og interne navne opløses kun for den klient, der blev forbundet sidst. Det mønster ligner en fejl i en af klienterne. Det er normalt det forudsigelige resultat af to programmer, der skriver den samme resolver-konfiguration uden aftale om, hvem der ejer hvilket navn.

Myten: den nyeste VPN ejer DNS

Der findes ingen generel regel om, at den nyeste forbindelse vinder. Hvad der sker, afhænger af platformsmekanismen og af, hvordan hver klient skriver den. En klient, der erstatter en resolver-fil, giver ét resultat; en klient, der tilføjer et domæne for hvert link, giver et andet; en klient, der ikke gør noget, lader den tidligere tilstand være intakt.

Så den observerede adfærd er en egenskab ved de to implementeringer, ikke en dokumenteret prioritet. At ræsonnere om det alene ud fra startrækkefølgen vil nogle gange være rigtigt og nogle gange forkert på måder, der er svære at reproducere. Skriv kortlægningen ned i stedet. Et design, der lever i to klienter, er ikke et design.

Kortlæg navnerum til resolvere

List de private suffikser og den resolver, som hvert netværk kræver, og beslut derefter, hvor offentlige navne skal hen. Den liste er designet. Uden den træffer klienterne beslutningen ved et uheld.

En platform, der understøtter DNS for hvert link eller routingdomæner, kan udtrykke opdelingen bevidst: ét domæne går til ét link, et andet domæne til det andet, og alt andet følger en eksplicit standard. To flade scripts, der overskriver den samme fil, kan ikke bevare det design, fordi hver af dem tror, den ejer hele konfigurationen.

På Windows kan tabellen for navneopløsningspolitik sende suffikser til bestemte servere, og en VPN-klient kan installere regler der. Kontroller politikken i stedet for adapterlisten, fordi det ikke er adapterlisten, der opløser navnet.

Behold en bootstrap-sti

Hver klient skal finde sit eget endepunkt, før den kan bruge den tjeneste, som endepunktet leverer. Hvis endepunktets værtsnavn kun kan opløses gennem tunnelen, og tunnelen har brug for det opløste værtsnavn, har du en cirkulær afhængighed, der viser sig som en forbindelsestimeout. Behold én bootstrap-sti uden for begge tunneler. Den koster intet indtil den dag, hvor den redder forbindelsen.

Se på stien til hver resolver, ikke kun det navn, der er konfigureret til den. En resolver, der kun kan nås gennem den anden tunnel, opfører sig som en manglende, og symptomet er en timeout i stedet for en routingfejl.

Overlappende adresser er ikke et DNS-problem

To private netværk med samme adresseområde kan ikke rettes med DNS-rækkefølge. Hvis begge tunneler gør krav på 10.0.0.0/8, peger et navn, der opløses korrekt, stadig på en adresse, som værten ikke kan route til den rigtige tunnel. Det kræver en løsning på adresseniveau, såsom forskellige områder, et navnerum eller oversættelse, ikke endnu en resolver-indstilling. At beslutte dette tidligt forhindrer en lang omvej gennem DNS-konfiguration, som aldrig ville have virket.

Sammenlign adressetildelingerne for begge tunneler, før du bebrejder navneopløsningen. Når begge parter skubber det samme præfiks, beholder værten én rute til det, og et navn, der opløses gennem den anden tunnel, lander stadig på en adresse, som den første tunnel ejer. Forskellige områder, et navnerum for hvert netværk eller oversættelse er rettelserne; efter hver klients forbindelse skal du bekræfte, at rutetabellen viser den sti, du havde til hensigt.

Bevis det med rigtige programmer

Vælg to værter, der kun findes i deres eget navnerum, og ét offentligt navn, og opløs derefter hver af dem gennem den klient, der bør eje den. Et korrekt svar fra den forventede resolver beviser ikke, at programmet når værten, fordi ruten til den adresse stadig kan fejle. Følg hvert opslag med en forbindelsestest fra det program, som brugeren faktisk vil køre.

En klient med sin egen krypterede DNS-indstilling kan omgå den politik, du netop har verificeret, så kontroller den indstilling som en del af gennemgangen. Genopret derefter forbindelsen til begge klienter i den rækkefølge, leverandøren understøtter, og gentag opslagene; hvis svarene bytter, når rækkefølgen ændres, ejer en konkurrerende skribent stadig en del af konfigurationen. Find ud af, hvilken komponent der installerer reglen - klienten, OS-profilen eller en administrationsagent - før du redigerer noget. Noter rækkefølgen og ejerne, så den næste person ikke skal genopdage dem.