Twee VPN's, een resolver: wie laas skryf, wen

Twee VPN-kliënte is gekoppel, een vir werk en een vir 'n laboratoriumnetwerk, en interne name los net op vir die kliënt wat laas gekoppel het. Daardie patroon lyk soos 'n fout in een van die kliënte. Dit is gewoonlik die voorspelbare gevolg van twee programme wat dieselfde oplosser-konfigurasie skryf sonder ooreenkoms oor wie watter naam besit.

Die mite: die nuutste VPN besit DNS

Daar is geen algemene reël dat die mees onlangse verbinding wen nie. Wat gebeur, hang af van die platformmeganisme en van hoe elke kliënt dit skryf. 'n Kliënt wat 'n oplosser-lêer vervang, lewer een uitkoms; 'n kliënt wat 'n domein per skakel byvoeg, lewer 'n ander; 'n kliënt wat niks doen nie, laat die vorige toestand ongeskonde.

Dus is die waargenome gedrag 'n eienskap van die twee implementasies, nie 'n gedokumenteerde prioriteit nie. Om daaroor te redeneer op grond van bekendstellingsorde alleen sal soms reg wees en verkeerd op maniere wat moeilik is om te herhaal. Skryf eerder die kartering neer. 'n Ontwerp wat in twee kliënte leef, is nie 'n ontwerp nie.

Karteer naamruimtes na oplossers

Lys die private agtervoegsels en die oplosser wat elke netwerk vereis, en besluit dan waar openbare name moet gaan. Daardie lys is die ontwerp. Sonder dit neem die kliënte die besluit per ongeluk.

'n Platform wat DNS per skakel of roeteringsdomeine ondersteun, kan die splitsing doelbewus uitdruk: een domein gaan na een skakel, 'n ander domein na die ander, en alles anders volg 'n eksplisiete verstek. Twee plat skrifte wat dieselfde lêer oorskryf, kan daardie ontwerp nie bewaar nie, want elkeen glo hy besit die hele konfigurasie.

Op Windows kan die naamoplossingsbeleidstabel agtervoegsels na spesifieke bedieners rig, en 'n VPN-kliënt kan reëls daar installeer. Kyk na die beleid eerder as na die adapterlys, want dit is nie die adapterlys wat die naam oplos nie.

Hou 'n bootstrap-pad oop

Elke kliënt moet sy eie eindpunt vind voordat dit die diens kan gebruik wat daardie eindpunt bied. As die eindpunt se gasheernaam net deur die tonnel opgelos kan word, en die tonnel die gasheernaam opgelos nodig het, het jy 'n kringafhanklikheid wat as 'n verbindingstydoorskryding verskyn. Hou een bootstrap-pad buite albei tonnels. Dit kos niks tot die dag wanneer dit die verbinding red.

Kyk na die pad na elke oplosser, nie net die naam wat daarvoor opgestel is nie. 'n Oplosser wat net deur die ander tonnel bereikbaar is, gedra hom soos een wat ontbreek, en die simptoom is 'n tydoorskryding eerder as 'n roeteringsfout.

Oorvleuelende adresse is nie 'n DNS-probleem nie

Twee private netwerke wat dieselfde adresreeks gebruik, kan nie deur DNS-orde reggestel word nie. As albei tonnels 10.0.0.0/8 opeis, wys 'n naam wat korrek oplos steeds na 'n adres waarnatoe die gasheer nie na die regte tonnel kan roeteer nie. Dit verg 'n oplossing op adresvlak, soos verskillende reekse, 'n naamruimte of vertaling, nie nog 'n oplosser-instelling nie. Om dit vroeg te besluit, voorkom 'n lang ompad deur DNS-konfigurasie wat nooit sou werk nie.

Vergelyk die adrestoewysings van albei tonnels voordat jy naamoplossing blameer. Wanneer albei eweknieë dieselfde voorvoegsel stuur, hou die gasheer een roete daarvoor, en 'n naam wat deur die tweede tonnel opgelos is, beland steeds op 'n adres wat die eerste tonnel besit. Verskillende reekse, 'n naamruimte per netwerk of vertaling is die regstellings; bevestig ná elke kliënt se verbinding dat die roetetabel die pad wys wat jy bedoel het.

Bewys dit met werklike toepassings

Kies twee gashere wat net in hul eie naamruimte bestaan en een openbare naam, en los dan elkeen op deur die kliënt wat dit behoort te besit. 'n Korrekte antwoord van die verwagte oplosser bewys nie dat die toepassing die gasheer bereik nie, want die roete na daardie adres kan steeds faal. Laat elke opsoeking volg deur 'n verbindingstoets uit die program wat die gebruiker werklik sal hardloop.

'n Kliënt met sy eie geënkripteerde DNS-opsie kan die beleid wat jy pas geverifieer het, omseil, so kyk na daardie instelling as deel van die oorsig. Herkoppel dan albei kliënte in die orde wat die verskaffer ondersteun en herhaal die opsoekings; as die antwoorde omruil wanneer die orde verander, besit 'n mededingende skrywer steeds deel van die konfigurasie. Vind watter komponent die reël installeer - die kliënt, die bedryfstelselprofiel of 'n bestuursagent - voordat jy enigiets wysig. Teken die orde en die eienaars aan sodat die volgende persoon dit nie weer hoef te ontdek nie.