Windows-a VPN-DNS-liko: kial la metriko venkas la itineron

Peto forlasas la maŝinon kaj atingas la hejman enkursigilon dum ĉiu pako estas tuneligata. La natura konkludo estas mankanta itinero, kaj la itinero kutime estas en ordo. Windows povas elekti per la interfaca metriko, kies solvilo estos demandita, kaj tunela adaptilo ofte malvenkas tiun komparon kontraŭ la sendrata.

Du klarigoj por unu liko

La itinera klarigo diras, ke parto de la trafiko eskapas la tunelon, do la defaŭlta itinero aŭ la listo de dividita tunelo devas esti malĝusta. Tiu klarigo testeblas per unu komando, kaj kiam la defaŭlta itinero montras en la tunelon, ĝi estas finita. Kontrolu ĝin unue, ĉar ĝi estas malmultekosta, kaj poste flankenmetu ĝin, kiam ĝi revenas pura.

La ranga klarigo diras, ke la trafiko estas plene tuneligata kaj la serĉo ankoraŭ estas sendata al alia solvilo. Windows traktas la elekton de solvilo kiel econ de ĉiu interfaco kun ordo, do fizika adaptilo kun pli bona metriko povas provizi DNS por nomo eĉ se la pakoj al la solvita adreso iras tra la tunelo. Ambaŭ klarigoj kaŭzas la saman simptomon sur lika testopaĝo, pro tio la testo ne estas la diagnozo. Nur unu el ili ripareblas per redaktado de itineroj.

Komparu metrikojn kaj solvilojn kune

Notu la interfacojn, ties metrikojn kaj ties agorditajn servilojn dum la tunelo funkcias. Legu ilin kiel tabelo, ne kiel du apartaj listoj, ĉar la demando estas, kiu solvilo venas unue, ne kiuj solviloj ekzistas.

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

Se la tunela adaptilo portas pli altan nombron ol la fizika, ĝia solvilo ne estas preferata, kaj interna nomo iros al tio, kion proponas la fizika flanko. Tiu enkursigilo povas respondi el kaŝmemoro, plusendi la peton aŭ rifuzi ĝin, kaj neniu el tiuj rezultoj estas la dezajno, kiun vi intencis. La ordo estas prefero, do ĝi silente malvenkas anstataŭ lanĉi eraron.

Tunela adaptilo tute sen agordita solvilo estas same ofta varianto. La kliento levigas la interfacon sen puŝi DNS, do la demando pri ordo eĉ ne aperas.

Altigu la tunelon kaj retestu

Donu al la tunela interfaco la plej malaltan metrikon, aŭ altigu la valoron de la fizika adaptilo, en ŝelo kun pliigitaj rajtoj. Ambaŭ estas agordoj por unuopa interfaco kaj ambaŭ estas malfareblaj, kio gravas kiam vi ŝanĝas maŝinon, antaŭ kiu vi eble ne sidas.

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

La ŝanĝo videblas tuj, kaj la DNS-kliento kaj aliaj konsumantoj kaŝmemorigas la elekton, kiun ili jam faris. Rekonektu la tunelon aŭ restartigu antaŭ ol legi ion en petan rezulton. Testo farita tro frue ripetos la malnovan konduton kaj aspektos kiel malsukcesa riparo.

Poste demandu unu internan kaj unu publikan nomon kaj kontrolu, kiu servilo respondis. La referenco pri aŭtomataj metrikoj de Microsoft klarigas, kial la plej malalta valoro estas preferata kaj kiel la aŭtomata atribuo estas derivata.

Igu ĝin postvivi rekonekton

Manuala metriko sur adaptilo, kiu estas rekreata ĉe ĉiu konekto, estas agordo, kiu malaperas. Se la kliento rekonstruas la interfacon, la anstataŭo bezonas skripton post konekto, politikon aŭ klientan agordon, kiu posedas DNS dum la konekto daŭras.

Statike agorditaj serviloj sur la fizika adaptilo havas la saman daŭrecan problemon inverse. Ili daŭre respondas por tiu interfaco ĝis ili estas forigitaj, kaj DHCP replenigos ilin el la sekva luo, do forigi ilin estas mezuro, ne dezajno. La daŭra dezajno estas nomrezolucia politiko por la interna nomspaco, aŭ kliento, kiu prenas posedon de DNS dum la daŭro de la konekto. Ĉiukaze notu la solvilan liston antaŭ kaj post rekonekto, restarigu la originan metrikon kiam vi finos testi, kaj konfirmu, ke la antaŭa konduto revenis.