Server DNS i gabuar në VPN Windows: metrikë, rend lidhjeje ose prapashtesë

Një klient Windows mund të ketë një tunel që funksionon, të mbajë zgjidhësin e korporatës dhe gjithsesi t'i dërgojë emrat e brendshëm ruterit të shtëpisë. Tre mekanizma të ndryshëm vendosin cili server përgjigjet, dhe dështojnë në mënyra të ndryshme. Nuk është e nevojshme t'i rregullosh të tre: simptoma të tregon cili është në lojë. Pema e vendimeve më poshtë merr disa minuta dhe parandalon rezultatin e zakonshëm, ku një ndryshim metrike, një rirenditje e regjistrit dhe një rregull NRPT vijnë së bashku dhe askush nuk e di cili bëri diçka.

Tre mekanizma vendosin, dhe zakonisht një është i gabuar

Metrika e ndërfaqes rendit përshtatësit për një familje të caktuar adresash. Rendi i lidhjes nën Tcpip\Linkage është një listë në nivel makine e identifikuesve të ndërfaqes që rrugët e vjetra të kodit ende konsultojnë. Tabela e Politikës së Zgjidhjes së Emrave (NRPT) lidh një hapësirë emrash me serverë të caktuar, dhe lista e prapashtesave vendos nëse një emër i shkurtër zgjerohet fare. Ato janë të pavarura, dhe për këtë arsye një zgjidhës i saktë në përshtatësin VPN humbet ndaj një preferimi të vjetruar diku tjetër.

Asnjë prej këtyre mekanizmave nuk është ana tjetër e tunelit. Nëse serveri që shtyn VPN-ja nuk mund ta zgjidhë emrin, çdo rregullim në anën e klientit është thjesht zbukurim, prandaj vendimi i parë është nëse vetë zgjidhësi mund të përgjigjet kur pyetet drejtpërdrejt.

Vendimi i parë: a mund të përgjigjet fare zgjidhësi i shtyrë?

Pyet serverin në mënyrë eksplicite dhe krahaso me një kërkim të zakonshëm. Diferenca midis përgjigjeve ndan një problem zgjedhjeje nga një problem arritshmërie, dhe këtu është degëzimi më i shpejtë:

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

Nëse i pari ka sukses dhe i dyti dështon, zgjidhësi është i arritshëm dhe Windows zgjedh keq; kalo te vendimet për hapësirën e emrave dhe rendin më poshtë. Nëse edhe i pari dështon, asgjë në klient nuk do të ndihmojë: kontrollo nëse UDP dhe TCP 53 arrijnë serverin përmes tunelit, nëse ndonjë mur zjarri i strehuesit në server nuk e hedh pishinën, dhe nëse përcjellësit e vetë serverit janë të shëndetshëm.

Ndalohu në këtë degëzim. Zbatimi i një rregulli NRPT në një zgjidhës që nuk mund ta arrish prodhon të njëjtin dështim me më shumë konfigurim për të anuluar, dhe fsheh defektin e vërtetë pas një rregulli që duket autoritar.

Vendimi i dytë: një hapësirë emrash apo çdo kërkesë?

Shtrirja vendos mjetin. Kur dështojnë vetëm emrat e korporatës, lidh hapësirën e emrave në vend që të rirenditësh makinën: një rregull NRPT e dërgon atë prapashtesë te zgjidhësi i tunelit dhe lë gjithçka tjetër në paqe. Kur preket çdo kërkim, problemi është preferimi global i përshtatësve, dhe metrika është vendi për të filluar sepse nuk ndryshon asnjë rregullim të serverit.

Vendos metrikën për çdo familje adresash, në të dy ndërfaqet, dhe pastaj konfirmo rendin:

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

Zëvendëso 11 me ifIndex të përshtatësit të tunelit nga rreshti më sipër; nëse 11 është përshtatësi LAN, i njëjti komandë ul rrugën e gabuar. Ngritja e përshtatësit LAN në vend të kësaj arrin të njëjtin rend nga ana tjetër: netsh int ip set interface interface="Ethernet" metric=15, dhe netsh int ipv6 set interface interface="Ethernet" metric=15 për familjen e dytë, sepse int ip prek vetëm IPv4.

Rendi i lidhjes është mjeti i fundit dhe jo hapi i parë. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage mban një listë Bind të identifikuesve të pajisjeve, dhe kalimi i identifikuesit të tunelit përpara ndryshon vërtet cili përshtatës pyetet i pari, por është një vlerë regjistri në nivel makine pa shtrirje për hapësirë emrash. Eksportoje para redaktimit dhe pastaj rilidh tunelin, që rendi të zbatohet në gjendjen që pret klienti.

Për një hapësirë të vetme emrash, prefero mjetin më të ngushtë:

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

Vendimi i tretë: a i mbijeton rregullimi një rilidhjeje?

Një metrikë që funksionon deri në rilidhjen tjetër me telefon nuk u ruajt kurrë. L2TP/IPsec dhe profilet e tjera të lidhjes rikrijohen kur fillon lidhja, prandaj vlera e ruajtur jeton në hyrjen e librit të telefonit si IpInterfaceMetric, jo vetëm në ndërfaqen aktive. Disa mjedise e skriptojnë atë fushë pikërisht për këtë arsye; të tjerë e shtyjnë preferimin nga një politikë menaxhimi dhe e lënë pikën fundore në paqe.

Cache dhe regjistrimi janë një shtresë më vete. Ekzekutimi i tyre pasi tuneli ngrihet rregullon hyrjet e vjetruara dhe e regjistron klientin përsëri, por asnjëra nuk e rirendit një përshtatës:

ipconfig /registerdns
ipconfig /flushdns

Në të njëjtën shtresë ka një çelës ndalimi. Çaktivizimi i regjistrimit dinamik në përshtatësin fizik e pengon klientin të shpallë adresën e tij nga ana e VPN nën emrin e gabuar, dhe ky është një rregullim i ndryshëm nga përditësimi më sipër.

IPv6 meriton rreshtin e vet në vendim. Nëse përshtatësi fizik ka një adresë IPv6 globale ndërsa tuneli mbart vetëm IPv4, Windows mund të preferojë rrugën pa tunel për zgjidhjen e emrave. Kontrollo atë familje veçmas, sepse një metrikë e vendosur për IPv4 nuk thotë asgjë për të:

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

Çaktivizimi i IPv6 në përshtatësin LAN heq atë rrugë dhe protokollin bashkë me të; një ndryshim metrike në ndërfaqen IPv6, ose një rregull NRPT për hapësirën e emrave të korporatës, e mban familjen dhe rregullon preferimin. Zgjidh më të ngushtën, përveç nëse ke vendosur që ajo lidhje nuk duhet të ketë IPv6.

Verifiko me burimin e emërtuar, dhe mbaj një pronar të vetëm

Verifiko me mjete që raportojnë cili burim është në fuqi, jo vetëm nëse ngarkohet një faqe:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

Pastaj ndaj filtrimin nga zgjedhja, sepse nga brenda një aplikacioni duken identike. block-outside-dns i OpenVPN bllokon portën 53 në përshtatësit e tjerë; nuk zgjedh një zgjidhës. Nëse tani dështon çdo kërkesë, një filtër mund të bllokojë serverin e vetëm të arritshëm; nëse zgjidhësi i konfiguruar injorohet, rendi ose rregulli i hapësirës së emrave është i gabuar. Ndryshimi i të dyjave njëherësh e bën një kërkesë të bllokuar dhe një kërkesë të injoruar të padallueshme.

Mbaj një pronar të vetëm për politikën e DNS: profilin VPN, një politikë menaxhimi ose një rregull NRPT, jo dy prej tyre. Para se ta mbyllësh:

• Zgjidhësi i shtyrë përgjigjet kur emërtohet eksplicit, dhe një kërkim i zakonshëm e përdor atë.
• Rregulli ose metrika që ndryshove mbulon familjen e adresave që vërtet mbart kërkesat.
• Rregullimi i mbijeton një shkëputjeje dhe rilidhjeje, ose e ke zhvendosur në profilin e ruajtur.
• Pikërisht një mekanizëm është autoritar, dhe të tjerët u lanë si ishin.

Trajto rendin si gjendje e mjedisit dhe jo si diçka që përfundon. Rikontrolloje pas një rilidhjeje dhe pas një përditësimi të Windows që prek stivën e rrjetit, sepse secili prej tyre mund ta kthejë përshtatësin fizik përpara.