VPN-ja mori DNS-në dhe theu emrat lokalë: rregullo listën

Tuneli ngrihet, intraneti ngarkohet dhe emri i printerit nuk zgjidhet më. Ose e kundërta: emrat lokalë vazhdojnë të punojnë ndërkohë që gjithçka brenda rrjetit të korporatës skadon. Të dy simptomat vijnë nga i njëjti vend, një listë zgjidhësish që klienti VPN e rishkruajti kur u lidh.

Rregullo listën me qëllim, pastaj merru veçmas me mekanizmin push. Rrugët janë një temë e tretë dhe nuk është ajo që rregullohet këtu.

Cilën listë përdorin në të vërtetë aplikacionet

Windows zgjidh përmes cilësimeve në nivel ndërfaqeje dhe jo përmes asaj që tregon një dialog, prandaj fillo me listat efektive për çdo ndërfaqe. Aliasi ka më shumë rëndësi sesa emri i shfaqur, sepse çdo komandë më poshtë i drejtohet një ndërfaqeje. Gabo aliasin dhe rregullimi do të bjerë mbi përshtatësin e gabuar. Do të duket se punon deri në rilidhjen tjetër, kur kthehet vetë zëri i tunelit.

Pyetja është cilët serverë përfunduan përpara dhe nëse erdhën si zëra statikë apo si qira DHCP. Të dy faktet përcaktojnë cilën rregullim ke në dispozicion.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Lexo daljen për përshtatësin e tunelit dhe për atë fizik, dhe shëno çdo adresë në secilin. Një zë statik mund të hiqet me politikë ose skript; një zë i dhënë nga DHCP është i lidhur me qiranë dhe do të kthehet, gjë që ndryshon rregullimin që duhet të zgjedhësh. Emrat në rrjetin e largët zgjidhen nga zgjidhësi i shpallur, emrat në LAN-in lokal nga përshtatësi fizik, dhe kërkesa shkon te lista që konsultohet e para.

Hiq serverët e shtyrë, ose vendosi më poshtë

Fshi serverët e shtyrë kur asgjë brenda tunelit nuk i nevojit, sepse zgjidhësit e vetë përshtatësit fizik marrin përsëri frenat. Mbaji vetëm nëse rrjeti i largët zotëron zona të cilave vetëm serverët e tij mund t'u përgjigjen, dhe në atë rast vendos një zgjidhës lokal përpara tyre. Dy komandat më poshtë mbulojnë të dyja zgjedhjet, prandaj zgjidh atë që përshtatet me situatën në vend që t'i ekzekutosh të dyja.

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

Indeksi 1 konsultohet i pari, prandaj adresat e shtyra mbeten në dispozicion por nuk janë më përgjigjja e parazgjedhur për çdo kërkesë. Flamuri validate=no anashkalon një test arritshmërie që shpesh dështon ndërsa tuneli ende po stabilizohet, prandaj konfirmo rezultatin me komandën show në vend që t'i besosh kodit të daljes.

Vlen të njohësh dy kufizime para se të mbështetesh në këtë. Windows nuk do t'i fshijë serverët që erdhën përmes DHCP nëpërmjet netsh, dhe ato vlera vazhdojnë si DhcpNameServer nën çelësin e regjistrit të ndërfaqes, prandaj redaktimi i regjistrit është mjeti i fundit që duhet rikontrolluar pas qirasë tjetër. Edhe rendi i lidhjes së përshtatësve nuk është mekanizëm i besueshëm renditjeje, sepse një klient VPN mund të fusë zërin e vet në krye të listës.

Ku mund të filtrohet push-i

Një rregullim më i mirë e heq opsionin para se të aplikohet. Klienti Community OpenVPN mund të filtrojë një direktivë të shtyrë sipas emrit, gjë që e lë konfigurimin e serverit të paprekur.

pull-filter ignore "dhcp-option DNS "

Hapësira në fund i takon përputhjes dhe filtri emërton opsionin, jo një adresë serveri. Nëse profili përmban edhe një direktivë block-outside-dns, heqja e saj ndryshon mbrojtjen nga rrjedhjet dhe jo zgjidhjen e emrave, prandaj vendos për këtë veçmas në vend që t'i bashkosh dy redaktimet.

Për një emër hosti kokëfortë, një rresht në skedarin hosts të Windows është më i qëndrueshëm sesa rirenditja e zgjidhësve për të gjithë makinën. Është gjithashtu i padukshëm për personin tjetër, prandaj shënoje aty ku dokumentohet konfigurimi i makinës.

Bëj që rregullimi t'i mbijetojë një rilidhjeje

Zgjidhja e emrave duhet testuar dy herë, një herë kundër një serveri të zgjedhur dhe një herë në formën që përdor një aplikacion. Ai çift ndan një problem të rendit të zgjidhësve nga një server që nuk përgjigjet fare. Nëse anashkalohet testi i parë, dy shkaqet mbeten të ngatërruara.

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

Rilidh tunelin dhe përsërit të dyja komandat. Çfarë ke ndryshuar me dorë zgjat vetëm deri në lidhjen tjetër, sepse klienti rindërton gjendjen e zgjidhësve ndërsa ngre përshtatësin. Vendos rreshtat netsh në skriptin e lidhjes të mbështetur të klientit tënd, lëre atë skript të përfundojë me sukses dhe shto një pritje të shkurtër para se të ekzekutohet. Një klient që aplikon DNS pas skriptit do ta mbishkruajë rezultatin gjithsesi.

Nëse emrat publikë zgjidhen dhe ata të brendshëm vazhdojnë të dështojnë pas rregullimit, lista e zgjidhësve nuk është më e dyshuara. Kërkesa ndoshta nuk arrin fare te serveri, gjë që tregon rrugëzim ose një rregull firewalls dhe jo një cilësim tjetër DNS. Shëno aliasin e ndërfaqes dhe adresat ku u ndalët, sepse të dyja ndryshojnë midis makinave dhe asnjëra nuk i mbijeton një rindërtimi vetëm.