To VPN-er, én resolver: den som skrev sist vinner

To VPN-klienter er koblet til, én for arbeid og én for et laboratorienettverk, og interne navn løses bare for klienten som koblet til sist. Dette mønsteret ser ut som en feil i en av klientene. Vanligvis er det det forutsigbare resultatet av to programmer som skriver samme resolver-konfigurasjon uten avtale om hvem som eier hvilket navn.

Myten: den nyeste VPN-en eier DNS

Det finnes ingen generell regel om at den nyeste tilkoblingen vinner. Hva som skjer avhenger av plattformmekanismen og av hvordan hver klient skriver den. En klient som erstatter en resolver-fil gir ett resultat; en klient som legger til et domene per lenke gir et annet; en klient som ikke gjør noe lar den forrige tilstanden være intakt.

Den observerte oppførselen er altså en egenskap ved de to implementasjonene, ikke en dokumentert prioritet. Å resonnere om det bare ut fra startrekkefølgen vil noen ganger være riktig og noen ganger feil på måter som er vanskelige å reprodusere. Skriv ned kartleggingen i stedet. Et design som lever i to klienter er ikke et design.

Kartlegg navnerom til resolvere

List opp de private suffiksene og resolveren hvert nettverk krever, og bestem deretter hvor offentlige navn skal gå. Den listen er designet. Uten den tar klientene avgjørelsen ved uhell.

En plattform som støtter DNS per lenke eller rutingsdomener kan uttrykke delingen bevisst: ett domene går til én lenke, et annet domene til den andre, og alt annet følger en eksplisitt standard. To flate skript som overskriver samme fil kan ikke bevare det designet, fordi hver av dem tror den eier hele konfigurasjonen.

På Windows kan navneoppløsningspolicy-tabellen sende suffikser til bestemte servere, og en VPN-klient kan installere regler der. Kontroller policyen i stedet for adapterlisten, fordi det ikke er adapterlisten som løser navnet.

Hold en bootstrap-sti

Hver klient må finne sitt eget endepunkt før den kan bruke tjenesten endepunktet tilbyr. Hvis vertsnavnet til endepunktet bare kan løses gjennom tunnelen, og tunnelen trenger det løste vertsnavnet, har du en sirkulær avhengighet som vises som tidsavbrudd for tilkoblingen. Hold én bootstrap-sti utenfor begge tunnelene. Den koster ingenting frem til dagen den redder tilkoblingen.

Se på stien til hver resolver, ikke bare navnet som er konfigurert for den. En resolver som bare er tilgjengelig gjennom den andre tunnelen oppfører seg som en som mangler, og symptomet er tidsavbrudd i stedet for en rutingsfeil.

Overlappende adresser er ikke et DNS-problem

To private nettverk med samme adresseområde kan ikke rettes med DNS-rekkefølge. Hvis begge tunnelene krever 10.0.0.0/8, peker et navn som løses riktig fortsatt på en adresse verten ikke kan rute til riktig tunnel. Det krever en løsning på adressenivå, som ulike områder, et navnerom eller oversettelse, ikke nok en resolver-innstilling. Å avgjøre dette tidlig forhindrer en lang omvei gjennom DNS-konfigurasjon som aldri ville ha virket.

Sammenlign adressetildelingene til begge tunnelene før du klandrer navneoppløsningen. Når begge parter skyver samme prefiks, beholder verten én rute for det, og et navn som løses gjennom den andre tunnelen lander fortsatt på en adresse den første tunnelen eier. Ulike områder, et navnerom per nettverk eller oversettelse er rettelsene; etter at hver klient er koblet til, bekreft at rutetabellen viser stien du hadde tenkt.

Bevis det med ekte programmer

Velg to verter som bare finnes i sitt eget navnerom og ett offentlig navn, og løs deretter hver av dem gjennom klienten som skal eie den. Et riktig svar fra den forventede resolveren beviser ikke at programmet når verten, fordi ruten til den adressen fortsatt kan svikte. Følg hvert oppslag med en tilkoblingstest fra programmet brukeren faktisk vil kjøre.

En klient med eget kryptert DNS-alternativ kan omgå policyen du nettopp verifiserte, så kontroller den innstillingen som en del av gjennomgangen. Koble deretter begge klientene til igjen i rekkefølgen leverandøren støtter, og gjenta oppslagene; hvis svarene bytter når rekkefølgen endres, eier en konkurrerende skribent fortsatt en del av konfigurasjonen. Finn ut hvilken komponent som installerer regelen - klienten, OS-profilen eller en administrasjonsagent - før du redigerer noe. Noter rekkefølgen og eierne slik at neste person ikke må gjenoppdage dem.