Bakit binabali ng malawak na ruta ng VPN ang ilang pampublikong site

Naglo-load ang karamihan ng pahina, dalawa o tatlo ang nag-time out, at sinisisi ng browser ang koneksyon. Ang mga site na nabibigo ay may isang bagay na karaniwan na wala sa mga gumagana: ang kanilang naresolbang address ay nahuhulog sa loob ng prefix na inilagay ng VPN. Ang rutang sapat ang lawak upang masakop ang pampublikong saklaw ay mahuhuli ang trapikong hindi kailanman dapat dalhin ng tunnel, at ang sintomas ay mukhang problema ng website sa halip na desisyon sa ruta.

I-resolba ang pangalang nabibigo, pagkatapos tingnan ang talahanayan ng ruta sa halip na ang browser.

Ihambing ang address, hindi ang pangalan ng site

Hanapin ang address na aktwal na sinubukan ng client, pagkatapos suriin kung aling ruta ang tumutugma rito. Ang destinasyong nasa loob ng 45.61.20.10 ay nasa ilalim ng 45.0.0.0/8 kung naroroon ang prefix na iyon, kahit walang kinalaman ang site mismo sa tunnel. Ang paghahambing ng nabibigong address sa mga naka-install na prefix ay problema sa pagbabawas, hindi haka-haka.

Kayang sagutin ng Windows ang parehong hati nang direkta, at ipinapakita ng paghahanap kung aling interface at susunod na hop ang nanalo sa pagpili. I-resolba ang pangalan nang dalawang beses kung maraming address ang ibinabalik ng site. Itala ang bawat isa kasama ang rutang tumugma. Maaaring magbigay ng magkaibang sagot ang magkaibang address, at isa lamang sa mga ito ang posibleng nabibigong kaso.

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

Basahin ang pinakaspesipikong tumutugmang prefix, hindi ang unang linyang mukhang pamilyar. Ang rutang nasa talahanayan ay hindi nagpapatunay na nanalo ito sa paghahanap; ang pinakamahabang tugma ang gumagawa niyon. Dalawang prefix ang maaaring tumugma sa isang address, at isa lamang ang tumatanggap ng packet. Ang natatalo ay nananatili sa talahanayan at mukhang kasing-totoo sa isang listahan.

Itala ang prefix, ang interface nito at ang naresolbang address. Ang tatlong halagang iyon ang buong diagnosis.

Alamin kung sino ang nag-install ng ruta

Ang mga ruta ay nagmumula sa apat na lugar: ang native na profile ng VPN, patakaran sa pamamahala, script ng koneksyon o ganap na ibang client. Maaaring kumpirmahin ng pagtanggal sa aktibong entry ang kaugnayan nito, ngunit muling ginagawa ito ng susunod na koneksyon mula sa naka-save na configuration, kaya ang pinagmulan ang dapat baguhin.

Suriin muna ang listahan ng ruta ng profile, pagkatapos ang patakaran sa pamamahala, pagkatapos ang anumang script na tumatakbo kapag kumokonekta. Ang pagkakasunod-sunod na iyon ay tumutugma sa kung gaano kadalas nagiging responsable ang bawat isa. Pinapanatili rin nito ang pagbabago sa isang layer sa halip na tatlo.

Basahin nang mabuti ang native na pag-uugaling nakabatay sa klase

Ang mga native na profile ng Windows ay may dokumentadong setting, NativeProfile/DisableClassBasedDefaultRoute, na kumokontrol sa awtomatikong rutang hinango mula sa address ng interface. Ang address ng profile na nagsisimula sa 45 ay maaaring gumawa ng entry na 45.0.0.0/8 sa ilalim ng pag-uugaling iyon, at ganoon nahuhuli ng isang pampublikong address ang buong saklaw ng class A.

Inaanyayahan ng pangalan ng property ang maling pagbasa: ang pagtatakda nito sa true ay nagpapahinto sa hinuha, at false ang nagpapagana. Hindi rin ito kaparehong bagay sa default na ruta, at hindi nito kinokontrol ang mga client ng third party na nag-iinstall ng sarili nilang prefix.

Kung ang hinuha ang napatunayang dahilan, ayusin ang profile sa pamamagitan ng may-ari ng pamamahala nito at tahasang ibigay ang inilaan na pribadong prefix. Kung ang isang script ang nagdagdag ng entry, ayusin ang script. Ang pagpapalit ng isang hindi maipaliwanag na malawak na ruta ng iba ay nagbabago ng sintomas nang hindi sinasagot ang tanong.

Ayusin ang pinagmulan, pagkatapos muling suriin ang dalawang landas

Pagkatapos ng pagbabago, kumonekta muli at ulitin ang paghahanap para sa nabibigong pampublikong site at para sa resource na dapat gumamit ng tunnel. Ang una ay dapat na ngayong maresolba sa pisikal na interface, at ang pangalawa ay dapat pang pumili ng VPN. Huwag huminto sa unang tagumpay; ang pagwawasto na sumisira rin ng pribadong access ay nagpalit ng isang depekto sa iba.

Sabay na suriin ang plano ng address ng server. Ang pool na nagsasapawan sa pampublikong espasyo ay paulit-ulit na nagdudulot ng ganitong uri ng problema. Ang saklaw na sinadyang pinili ng operator ay karapat-dapat sa ibang usapan, hindi sa awtomatikong muling pagbilang.

Ang pagtaas ng MTU o paglilinis ng DNS ay hindi magwawasto ng prefix na nagpapadala pa rin ng address na iyon sa tunnel. Subukan muna ang pagpili, pagkatapos ang landas.