Mteja wa Windows anaweza kuwa na handaki inayofanya kazi, kubeba kisisitizaji cha kampuni na bado kutuma majina ya ndani kwa rauta ya nyumbani. Mbinu tatu tofauti huamua ni seva gani itajibu, na hushindwa kwa namna tofauti. Huna haja ya kurekebisha zote tatu: dalili inakuambia ipi iko kazini. Mti wa maamuzi hapa chini huchukua dakika chache na huzuia matokeo ya kawaida, ambapo mabadiliko ya metriki, upangaji upya wa rejista na kanuni ya NRPT huja pamoja na hakuna anayejua ipi ilifanya kitu.

Mbinu tatu huamua, na kwa kawaida moja si sahihi

Metriki ya kiolesura hupanga adapta kwa familia fulani ya anwani. Mpangilio wa kuunganisha chini ya Tcpip\Linkage ni orodha ya ngazi ya mashine ya vitambulisho vya kiolesura ambayo njia za msimbo wa zamani bado huzingatia. Jedwali la Sera ya Utatuzi wa Majina (NRPT) hufunga nafasi ya majina kwa seva mahususi, na orodha ya kiambishi huamua kama jina fupi hupanuliwa kabisa. Hizi ni huru, na ndiyo sababu kisisitizaji sahihi kwenye adapta ya VPN hushindwa na upendeleo wa kizamani mahali pengine.

What you seeMechanism to checkFirst command
Every name is slow, public names sometimes wrongGlobal adapter order: metric, then LinkageGet-NetIPInterface
Internal names resolve to a public addressThe query left through the home resolver, not the tunnelResolve-DnsName intranet.corp.example -Type A, then the same query with -Server 10.20.0.10
Only corp.example names fail, public names fineNamespace binding: NRPT or suffixGet-DnsClientNrptRule
Short name fails, fully qualified name worksSuffix list on the adapter, with the corporate suffix ahead of other entries, or pushed by the serverGet-DnsClientGlobalSetting
Works, then breaks after a reconnectRuntime setting that was never persistedGet-VpnConnection for the stored profile, then Get-NetIPInterface again after a reconnect

Hakuna moja ya mbinu hizi ni upande wa pili wa handaki. Ikiwa seva ambayo VPN inasukuma haiwezi kutatu jina, kila mpangilio upande wa mteja ni pambo tu, kwa hiyo uamuzi wa kwanza ni kama kisisitizaji chenyewe kinaweza kujibu kinapoulizwa moja kwa moja.

Uamuzi wa kwanza: kisisitizaji kilichosukumwa kinaweza kujibu kabisa?

Uliza seva kwa uwazi na linganisha na utafutaji wa kawaida. Pengo kati ya majibu hutenganisha tatizo la uchaguzi na tatizo la ufikivu, na hapa ndio tawi la haraka zaidi:

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

Ikiwa la kwanza linafanikiwa na la pili linashindwa, kisisitizaji kinafikika na Windows inachagua vibaya; nenda kwenye maamuzi ya nafasi ya majina na mpangilio hapa chini. Ikiwa la kwanza pia linashindwa, hakuna kitu kwenye mteja kitakachosaidia: angalia kama UDP na TCP 53 zinafika kwa seva kupitia handaki, kama hakuna ukuta wa moto wa mwenyeji kwenye seva unaotupa dimbwi, na kama visambazaji vya seva yenyewe viko sawa.

Simama kwenye tawi hili. Kutumia kanuni ya NRPT kwa kisisitizaji usichoweza kufikia huleta kushindwa kulekule na mpangilio zaidi wa kuondoa, na huficha hitilafu halisi nyuma ya kanuni inayoonekana kuwa na mamlaka.

Uamuzi wa pili: nafasi moja ya majina au kila swali?

Wigo huamua chombo. Wakati majina ya kampuni pekee yanashindwa, funga nafasi ya majina badala ya kupanga upya mashine: kanuni ya NRPT hutuma kiambishi hicho kwa kisisitizaji cha handaki na kuacha kila kitu kingine. Wakati kila utafutaji unaathiriwa, tatizo ni upendeleo wa jumla wa adapta, na metriki ndio mahali pa kuanzia kwa sababu haibadilishi mpangilio wowote wa seva.

Weka metriki kwa kila familia ya anwani, kwenye violesura vyote viwili, kisha thibitisha mpangilio:

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

Badilisha 11 na ifIndex ya adapta ya handaki kutoka mstari ulio juu; ikiwa 11 ni adapta ya LAN, amri hiyo hiyo hushusha njia isiyo sahihi. Kupandisha adapta ya LAN badala yake hufikia mpangilio huo huo kutoka upande mwingine: netsh int ip set interface interface="Ethernet" metric=15, na netsh int ipv6 set interface interface="Ethernet" metric=15 kwa familia ya pili, kwa sababu int ip hugusa IPv4 pekee.

Mpangilio wa kuunganisha ni suluhisho la mwisho na si hatua ya kwanza. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage inashikilia orodha ya Bind ya vitambulisho vya kifaa, na kuhamisha kitambulisho cha handaki mbele hubadilisha kweli ni adapta gani inaulizwa kwanza, lakini ni thamani ya rejista ya ngazi ya mashine bila wigo kwa kila nafasi ya majina. Hamisha nje kabla ya kuhariri kisha unganisha tena handaki, ili mpangilio utumike katika hali ambayo mteja anatarajia.

Kwa nafasi moja ya majina, pendelea chombo chembamba zaidi:

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

Uamuzi wa tatu: marekebisho yanastahimili kuunganishwa upya?

Metriki inayofanya kazi hadi muunganisho unaofuata wa simu haikuwahi kuhifadhiwa. L2TP/IPsec na profaili nyingine za muunganisho huundwa upya muunganisho unapoanza, kwa hiyo thamani iliyohifadhiwa huishi katika ingizo la kitabu cha simu kama IpInterfaceMetric, si kwenye kiolesura hai pekee. Mazingira mengine huandika sehemu hiyo kwa script kwa sababu hii hasa; mengine husukuma upendeleo kutoka sera ya usimamizi na kuacha kituo cha mwisho.

Akiba na usajili ni tabaka tofauti. Kuziendesha baada ya handaki kupanda hurekebisha maingizo ya kizamani na kusajili mteja upya, lakini hakuna hata moja inayopanga upya adapta:

ipconfig /registerdns
ipconfig /flushdns

Kuna swichi ya kuzima katika tabaka hilo hilo. Kuzima usajili unaobadilika kwenye adapta halisi huzuia mteja kutangaza anwani yake ya upande wa VPN chini ya jina lisilo sahihi, na huo ni urekebishaji tofauti na ule wa juu.

IPv6 inastahili mstari wake katika uamuzi. Ikiwa adapta halisi ina anwani ya kimataifa ya IPv6 wakati handaki inabeba IPv4 pekee, Windows inaweza kupendelea njia isiyo ya handaki kwa utatuzi wa majina. Angalia familia hiyo kwa tofauti, kwa sababu metriki iliyowekwa kwa IPv4 haisemi kitu juu yake:

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

Kuzima IPv6 kwenye adapta ya LAN huondoa njia hiyo na itifaki pamoja nayo; mabadiliko ya metriki kwenye kiolesura cha IPv6, au kanuni ya NRPT kwa nafasi ya majina ya kampuni, huhifadhi familia na kurekebisha upendeleo. Chagua chembamba zaidi, isipokuwa umeamua kwamba kiungo hicho hakipaswi kuwa na IPv6.

Thibitisha kwa chanzo kilichotajwa, na shikilia mmiliki mmoja

Thibitisha kwa zana zinazoripoti chanzo kipi kiko kazini, si tu kama ukurasa unapakia:

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

Kisha tenganisha uchujaji na uchaguzi, kwa sababu kutoka ndani ya programu huonekana sawa. block-outside-dns ya OpenVPN huzuia mlango 53 kwenye adapta nyingine; haichagui kisisitizaji. Ikiwa sasa kila swali linashindwa, kichujio kinaweza kuzuia seva pekee inayofikika; ikiwa kisisitizaji kilichosanidiwa kinapuuzwa, mpangilio au kanuni ya nafasi ya majina si sahihi. Kubadilisha vyote viwili kwa pamoja hufanya swali lililozuiwa na swali lililopuuzwa visivyoweza kutofautishwa.

Shikilia mmiliki mmoja wa sera ya DNS: profaili ya VPN, sera ya usimamizi au kanuni ya NRPT, si mbili kati ya hizo. Kabla ya kuifunga:

  • Kisisitizaji kilichosukumwa hujibu kinapotajwa kwa uwazi, na utafutaji wa kawaida hukitumia.
  • Kanuni au metriki uliyobadilisha inashughulikia familia ya anwani ambayo kwa kweli inabeba maswali.
  • Mpangilio unastahimili kukatika na kuunganishwa upya, au umeuhamisha kwenye profaili iliyohifadhiwa.
  • Mbinu moja hasa ina mamlaka, na nyingine ziliachwa kama zilivyokuwa.

Chukulia mpangilio kama hali ya mazingira na si kitu unachokamilisha. Uangalie tena baada ya kuunganishwa upya na baada ya sasisho la Windows linalogusa mkusanyiko wa mtandao, kwa sababu lolote kati ya hayo linaweza kurudisha adapta halisi mbele.

Makala zinazohusiana