To VPN-ar, éin resolver: den som skreiv sist vinn

To VPN-klientar er kopla til, éin for arbeid og éin for eit laboratorienettverk, og interne namn blir løyste berre for klienten som kopla til sist. Dette mønsteret ser ut som ein feil i ein av klientane. Vanlegvis er det det føreseielege resultatet av to program som skriv same resolver-konfigurasjon utan avtale om kven som eig kva namn.

Myten: den nyaste VPN-en eig DNS

Det finst ingen generell regel om at den nyaste tilkoplinga vinn. Kva som skjer avheng av plattformmekanismen og av korleis kvar klient skriv han. Ein klient som byter ut ei resolver-fil gir eitt resultat; ein klient som legg til eit domene per lenkje gir eit anna; ein klient som ikkje gjer noko lèt den førre tilstanden vere intakt.

Den observerte åtferda er altså ein eigenskap ved dei to implementasjonane, ikkje ein dokumentert prioritet. Å resonnere om det berre ut frå startrekkjefølgja vil nokre gonger vere rett og nokre gonger feil på måtar som er vanskelege å reprodusere. Skriv ned kartlegginga i staden. Eit design som lever i to klientar er ikkje eit design.

Kartlegg namnerom til resolverar

List opp dei private suffiksa og resolveren kvart nettverk krev, og avgjer deretter kvar offentlege namn skal gå. Den lista er designet. Utan henne tek klientane avgjerda ved uhell.

Ein plattform som støttar DNS per lenkje eller rutingsdomene kan uttrykke delinga medvite: eit domene går til éi lenkje, eit anna domene til den andre, og alt anna følgjer ein eksplisitt standard. To flate skript som overskriv same fil kan ikkje bevare det designet, fordi kvar av dei trur han eig heile konfigurasjonen.

På Windows kan navneoppløysingspolicy-tabellen senda suffiks til bestemte tenarar, og ein VPN-klient kan installere reglar der. Kontroller policyen i staden for adapterlista, fordi det ikkje er adapterlista som løyser namnet.

Hald ein bootstrap-sti

Kvar klient må finne sitt eige endepunkt før han kan bruke tenesta endepunktet tilbyr. Viss vertsnamnet til endepunktet berre kan løysast gjennom tunnelen, og tunnelen treng det løyste vertsnamnet, har du ein sirkulær avhengigheit som viser seg som tidsavbrot for tilkoplinga. Hald éin bootstrap-sti utanfor begge tunnelane. Han kostar ingenting fram til dagen han reddar tilkoplinga.

Sjå på stien til kvar resolver, ikkje berre namnet som er konfigurert for han. Ein resolver som berre er tilgjengeleg gjennom den andre tunnelen oppfører seg som ein som manglar, og symptomet er tidsavbrot i staden for ein rutefeil.

Overlappande adresser er ikkje eit DNS-problem

To private nettverk med same adresseområde kan ikkje rettast med DNS-rekkjefølgje. Viss begge tunnelane krev 10.0.0.0/8, peikar eit namn som blir løyst rett framleis på ei adresse verten ikkje kan rute til rett tunnel. Det krev ei løysing på adressenivå, som ulike område, eit namnerom eller omsetjing, ikkje nok ei resolver-innstilling. Å avgjere dette tidleg hindrar ein lang omveg gjennom DNS-konfigurasjon som aldri ville ha verka.

Samanlikn adressetildelingane til begge tunnelane før du klandrar navneoppløysinga. Når begge partar skyv same prefiks, held verten éin rute for det, og eit namn som blir løyst gjennom den andre tunnelen landar framleis på ei adresse den første tunnelen eig. Ulike område, eit namnerom per nettverk eller omsetjing er rettingane; etter at kvar klient er kopla til, stadfest at rutetabellen viser stien du hadde tenkt.

Prov det med ekte program

Vel to vertar som berre finst i sitt eige namnerom og eitt offentleg namn, og løys deretter kvar av dei gjennom klienten som skal eige det. Eit rett svar frå den forventa resolveren provar ikkje at programmet når verten, fordi ruta til den adressa framleis kan svikte. Følg kvart oppslag med ein tilkoplingstest frå programmet brukaren faktisk vil køyre.

Ein klient med eige kryptert DNS-alternativ kan omgå policyen du nettopp verifiserte, så kontroller den innstillinga som ein del av gjennomgangen. Kopla deretter begge klientane til att i rekkjefølgja leverandøren støttar, og gjenta oppslaga; viss svara byter når rekkjefølgja endrar seg, eig ein konkurrerande skrivar framleis ein del av konfigurasjonen. Finn ut kva komponent som installerer regelen - klienten, OS-profilen eller ein administrasjonsagent - før du redigerer noko. Noter rekkjefølgja og eigarane slik at neste person ikkje må gjenoppdage dei.