Kial larĝa VPN-itinero rompas kelkajn publikajn retejojn

Plej multaj paĝoj ŝarĝiĝas, du aŭ tri tempas ekstere, kaj la retumilo kulpas la konekton. La retejoj, kiuj malsukcesas, havas ion komunan, kion la funkciantaj ne havas: iliaj solvitaj adresoj falas en prefikson, kiun instalas la VPN. Itinero sufiĉe larĝa por kovri publikan gamon kaptos trafikon, kiun la tunelo neniam devis porti, kaj la simptomo aspektas kiel problema retejo anstataŭ kiel itinera decido.

Solvu la malsukcesan nomon, poste rigardu la itineran tabelon anstataŭ la retumilon.

Komparu la adreson, ne la retejan nomon

Serĉu la adreson, kiun la kliento efektive provis, poste kontrolu, kiu itinero kongruas kun ĝi. Celo ene de 45.61.20.10 falas sub 45.0.0.0/8 se tiu prefikso ĉeestas, eĉ se la retejo mem tute ne rilatas al la tunelo. Kompari la malsukcesan adreson kun la instalitaj prefiksoj estas subtraha problemo, ne konjekto.

Vindozo povas respondi al ambaŭ duonoj rekte, kaj serĉo montras, kiu interfaco kaj sekva salto gajnis la elekton. Solvu la nomon dufoje se la retejo redonas plurajn adresojn. Notu ĉiun kun la itinero, kiu kongruis. Malsamaj adresoj povas doni malsamajn respondojn, kaj nur unu el ili eble estas la malsukcesa kazo.

Resolve-DnsName www.example.org
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 45.61.20.10
Get-VpnConnection | Format-List Name,SplitTunneling,Routes

Legu la plej specifan kongruan prefikson, ne la unuan linion, kiu aspektas konata. Itinero ĉeestanta en la tabelo ne pruvas, ke ĝi gajnis la serĉon; la plej longa kongruo faras tion. Du prefiksoj povas kongrui kun unu adreso, kaj nur unu el ili ricevas la paketon. La malgajninto restas en la tabelo kaj aspektas same reala en listo.

Notu la prefikson, ĝian interfacon kaj la solvitan adreson. Tiuj tri valoroj estas la tuta diagnozo.

Trovu, kiu instalas la itineron

Itineroj venas el kvar lokoj: la propra VPN-profilo, administra politiko, konekta skripto aŭ tute alia kliento. Forigi la vivan eron povas konfirmi ĝian gravecon, sed la sekva konekto rekreas ĝin el la konservita agordo, do la fonto estas tio, kion oni devas ŝanĝi.

Kontrolu unue la itineran liston de la profilo, poste la administran politikon, poste ajnan skripton, kiu ruliĝas dum konekto. Tiu ordo kongruas kun tio, kiel ofte ĉiu el ili montriĝas respondeca. Ĝi ankaŭ tenas la ŝanĝon en unu tavolo anstataŭ tri.

Legu la propran klasbazitan konduton atente

Propraj Vindozaj profiloj havas dokumentitan agordon, NativeProfile/DisableClassBasedDefaultRoute, kiu regas aŭtomatan itineron derivitan el la interfaca adreso. Profila adreso komenciĝanta per 45 povas sub tiu konduto produkti eron 45.0.0.0/8, kaj tiel unu publika adreso kaptas tutan gamon de klaso A.

La nomo de la eco invitas al malĝusta legado: agordi ĝin al true malŝaltas la derivadon, kaj false ŝaltas ĝin. Ĝi ankaŭ ne estas la sama objekto kiel defaŭlta itinero, kaj ĝi ne regas triapartajn klientojn, kiuj instalas siajn proprajn prefiksojn.

Se la derivado estas la pruvita kaŭzo, riparu la profilon per ĝia administra posedanto kaj eksplicite provizu la celitajn privatajn prefiksojn. Se skripto aldonis la eron, riparu la skripton. Anstataŭigi unu neklarigitan larĝan itineron per alia ŝanĝas la simptomon sen respondi la demandon.

Riparu la fonton, poste rekontrolu ambaŭ vojojn

Post la ŝanĝo, rekonektu kaj ripetu la serĉon por malsukcesa publika retejo kaj por rimedo, kiu devas uzi la tunelon. La unua nun devus solviĝi al la fizika interfaco, kaj la dua devus ankoraŭ elekti la VPN. Ne haltu ĉe la unua sukceso; riparo, kiu ankaŭ rompas privatan aliron, interŝanĝis unu paneon kontraŭ alia.

Revizuu samtempe la adresan planon de la servilo. Baseno sin overlapanta kun publika spaco kaŭzas ĉi tiun klason de problemo ree kaj ree. Gamo, kiun la operaciisto elektis intence, meritas alian konversacion, ne aŭtomatan renumeradon.

Pliigi la MTU aŭ malplenigi DNS ne korektos prefikson, kiu ankoraŭ direktas tiun adreson en la tunelon. Testu unue la elekton, poste la vojon.