VPN prenis DNS kaj rompis lokajn nomojn: riparu la liston

La tunelo ekfunkcias, la intraneto ŝargiĝas, kaj la nomo de la printilo ĉesas solviĝi. Aŭ inverse: lokaj nomoj ankoraŭ funkcias dum ĉio ene de la kompania reto finiĝas per tempolimo. Ambaŭ simptomoj venas de la sama loko, solvila listo, kiun la VPN-kliento reskribis kiam ĝi konektiĝis.

Riparu la liston intence, poste traktu la puŝan mekanismon aparte. Itineroj estas tria temo kaj ne tiu, kiu estas riparata ĉi tie.

Kiun liston aplikoj efektive uzas

Windows solvas per agordoj sur interfaca nivelo, ne per tio, kion montras iu dialogujo, do komencu per la efektivaj listoj por ĉiu interfaco. La alinomo pli gravas ol la montrata nomo, ĉar ĉiu komando sube sin direktas al interfaco. Se vi eraros pri la alinomo, la riparo surteriĝos sur la malĝusta adaptilo. Ĝi ŝajnos funkcii ĝis la sekva rekonekto, kiam revenos la propra enskribo de la tunelo.

La demando estas, kiuj serviloj venis antaŭen kaj ĉu ili alvenis kiel statikaj enskriboj aŭ kiel DHCP-luo. Ambaŭ faktoj decidas, kiu riparo disponeblas al vi.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Legu la eligon por la tunela adaptilo kaj por la fizika, kaj notu ĉiun adreson sur ambaŭ. Statikan enskribon eblas forigi per politiko aŭ skripto; per DHCP ricevita enskribo estas ligita al la luo kaj revenos, kio ŝanĝas la riparadon, kiun vi devus elekti. Nomojn en la fora reto solvas la anoncita solvilo, nomojn en la loka LAN la fizika adaptilo, kaj la demando iras al tiu listo, kiu estas konsultata unue.

Forigu la puŝitajn servilojn aŭ ordigu ilin pli malalte

Forigu la puŝitajn servilojn kiam nenio ene de la tunelo bezonas ilin, ĉar la propraj solviloj de la fizika adaptilo denove transprenas. Konservu ilin nur se la fora reto posedas zonojn, kiujn nur ĝiaj serviloj povas respondi, kaj en tiu kazo metu lokan solvilon antaŭ ili. La du komandoj sube kovras ambaŭ elektojn, do elektu tiun, kiu konvenas al la situacio, anstataŭ ruli ambaŭ.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

Indekso 1 estas konsultata unue, do la puŝitaj adresoj restas disponeblaj sed ĉesas esti la defaŭlta respondo al ĉiu demando. La flago validate=no preterlasas atingeblan provon, kiu ofte malsukcesas dum la tunelo ankoraŭ stabiliĝas, do konfirmu la rezulton per la komando show anstataŭ fidi la elirkodon.

Indas koni du limojn antaŭ ol fidi ĉi tion. Windows ne forigos servilojn, kiuj alvenis per DHCP tra netsh, kaj tiuj valoroj restas kiel DhcpNameServer sub la registra ŝlosilo de la interfaco, do registra redakto estas lasta rimedo, kiu devas esti rekontrolita post la sekva luo. Ankaŭ la bindordo de adaptiloj ne estas fidinda viciga mekanismo, ĉar VPN-kliento povas enmeti sian propran enskribon ĉe la pinto de la listo.

Kie la puŝo povas esti filtrita

Pli bona riparo forigas la opcion antaŭ ol ĝi aplikiĝas. La kliento Community OpenVPN povas filtri puŝitan direktivon laŭ nomo, kio lasas la agordon de la servilo netuŝita.

pull-filter ignore "dhcp-option DNS "

La fina spaco apartenas al la kongruo kaj la filtrilo nomas la opcion, ne servilan adreson. Se la profilo ankaŭ enhavas direktivon block-outside-dns, forigi ĝin ŝanĝas likan protekton, ne nomosolvadon, do decidu pri tio aparte anstataŭ kunigi la du redaktojn.

Por unu obstina gastigantnomo, unu linio en la Windows-hosts-dosiero estas pli stabila ol reordigi solvilojn por la tuta maŝino. Ĝi ankaŭ estas nevidebla por la sekva persono, do notu ĝin tie, kie la agordo de la maŝino estas dokumentata.

Igu la riparon postvivi rekonekton

La nomosolvado devas esti testita dufoje, unufoje kontraŭ elektita servilo kaj unufoje en la formo, kiun uzas aplikaĵo. Tiu duopo apartigas problemon de solvila ordo de servilo, kiu tute ne respondas. Se la unua testo estas preterlasita, la du kaŭzoj restas interplektitaj.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Rekonektu la tunelon kaj ripetu ambaŭ komandojn. Kion vi ŝanĝis permane, teniĝas nur ĝis la sekva konekto, ĉar la kliento rekonstruas sian solvilan staton dum ĝi levas la adaptilon. Metu la liniojn netsh en la subtenatan konektan skripton de via kliento, lasu tiun skripton finiĝi sukcese, kaj aldonu mallongan atendon antaŭ ol ĝi ruliĝas. Kliento, kiu aplikas DNS post la skripto, ĉiuokaze anstataŭigos la rezulton.

Se publikaj nomoj solviĝas kaj internaj ankoraŭ malsukcesas post la riparo, la solvila listo ĉesis esti la suspektato. La demando verŝajne tute ne atingas la servilon, kio montras al enkursigo aŭ fajroŝirma regulo, ne al alia DNS-agordo. Notu la interfacan alinomon kaj la adresojn, ĉe kiuj vi haltis, ĉar ambaŭ malsamas inter maŝinoj kaj nek unu postvivas rekonstruon sole.