Paano Alisin ang Lipas na Ruta na Iniwan ng Windows VPN
Hanapin ang entry na talagang lipas na, i-preview ang pag-alis nito laban sa tamang policy store, at kumpirmahin na pinipili ng lookup ang interface na inaasahan mo.
Natapos ang session mo ilang oras na ang nakalipas, wala na ang adapter, ngunit nasa talahanayan pa rin ang ruta at nakaturo sa interface 42. Ang pagbura sa linyang iyon ay isang utos; ang pagpapasyang iyon ang tamang linya ay nangangailangan ng apat na pagsusuri. Ang talahanayan ng ruta ay pinagsasaluhan, kaya ang malawak na pag-alis ay nag-aalis ng mga landas na ginagamit pa ng ibang koneksyon, kasama ang nagdadala ng tunnel. Bawat hakbang sa ibaba ay nagpapaliit sa target hanggang isang entry lang ang maaaring tumugma.
1. Magpasya kung ang entry ay lipas na o sinadya
Ang entry na nakaligtas sa reboot ay isinulat sa isang lugar, at ang lugar na iyon ay karaniwang desisyon, hindi aksidente. Ang split tunneling ay umaasa sa mga rutang eksaktong mukhang tira, at ang patakarang nagtutulak ng isang prefix sa tunnel ay hindi makikilala sa lipas na entry sa isang listahan. Itanong kung kailan lumitaw ang ruta: ang umiiral lamang habang aktibo ang tunnel ay pag-aari ng configuration ng client, kaya ang cleanup command ay maling kasangkapan. Alisin ang sinadyang ruta at mabibigo ang susunod na koneksyon sa hakbang na walang nanonood.
Ang ruta ng endpoint ay karapat-dapat sa sarili nitong babala. Kapag nagdagdag ang client ng host route patungo sa VPN server upang maabot ito ng mga naka-encrypt na packet sa lokal na koneksyon, ang pagbura sa rutang iyon ay pinapabagsak ang tunnel sa susunod na muling pagkonekta, at ang sintomas ay binabasa bilang sira ng server. Bago hawakan ang anuman, ihambing ang destinasyon sa address na kinokonektahan ng client: isang pampublikong address na tumutugma sa VPN server ang panlabas na landas, hindi basura.
2. Itala ang apat na field na nagpangalan sa entry
Ang prefix lamang ay hindi pagkakakilanlan, dahil dalawang interface ay maaaring may mga ruta patungo sa parehong destinasyon. Itala ang destination prefix, interface index, susunod na hop at policy store, dahil ang apat na halagang iyon ay naglalarawan ng eksaktong isang entry. Isang listahan ang nagbibigay sa iyo ng lahat:
Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetricAng pag-uuri ayon sa metric ay nag-aangat sa mga rutang talagang ginusto ng makina, at doon karaniwang nakaupo ang tira. Ihambing ang entry habang aktibo ang tunnel at muli pagkatapos itong bumagsak: ang rutang nawawala kasama ng adapter ay pag-aari ng client, at ang natitira ay isinulat ng ibang bagay. Ang policy store ang field na nilalaktawan ng mga tao, at ito ang nagpapaliwanag ng muling paglitaw, dahil ang entry na inalis mula sa active store ay bumabalik pagkatapos ng susunod na pag-refresh ng patakaran. Itala ang apat na halaga bago magpatakbo ng anumang bagay na nagbabago ng estado.
3. I-preview ang pag-alis, pagkatapos ay alisin ang isang entry
Tumatanggap ang Remove-NetRoute ng parehong prefix at interface index na inilathala ng Get-NetRoute, at mayroon itong preview switch, kaya walang kailangang hulaan. Patakbuhin ang pares sa ganitong pagkakasunod-sunod:
Remove-NetRoute -DestinationPrefix 10.20.0.0/16 -InterfaceIndex 42 -WhatIf
Remove-NetRoute -DestinationPrefix 10.20.0.0/16 -InterfaceIndex 42Ang preview ay naglilimbag ng object na buburahin nito, kaya ihambing ang prefix, interface at susunod na hop sa iyong mga tala bago bitawan ang switch. Wala sa mga linya ang umabot sa permanenteng entry, dahil default ang active store; idagdag ang -PolicyStore PersistentStore kapag ang rutang natukoy mo ay nakatira doon, kung hindi ay tila gumana ang pag-alis at babalik ang entry sa susunod na pag-refresh ng patakaran. Panatilihin ang out-of-band recovery path kapag malayo ang session, dahil ang pagbura sa rutang nagdadala ng sarili mong koneksyon ay nagtatapos nito. Huwag kailanman abutin ang utos na naglilinis ng talahanayan.
4. Hanapin kung aling bahagi ang nagbabalik nito
Ang pag-alis ay hindi pag-aayos habang ang may-ari ay naka-configure pa ring i-install ang ruta. Ang may-ari ay karaniwang isa sa tatlo: ang profile ng VPN client kasama ang split-tunnel list nito, isang script o naka-iskedyul na gawain na nagdadagdag ng ruta sa pag-log on, o isang domain policy na inilapat sa makina. Suriin muna ang profile, dahil tumatakbo ito sa bawat koneksyon:
Get-VpnConnection | Select-Object Name,SplitTunneling,ServerAddress
Get-NetRoute -PolicyStore PersistentStoreAng mga permanenteng entry ay nakikita nang hindi kinokonekta ang anuman, kaya ang rutang bumabalik pagkatapos ng reboot na walang session ng VPN ay halos palaging nakatira sa store na iyon o sa startup script. Itama ang may-ari doon, at ang manu-manong pag-alis ay nagiging pagpapatunay sa halip na paggamot.
5. I-verify ang lookup, ang mga kapitbahay at ang tala
Ang malinis na resulta ay hindi ang nawala na ruta; ito ay lookup na ngayon ay pumipili ng interface na inaasahan mo. Itanong sa makina kung saan pupunta ang packet patungo sa apektadong prefix, dahil ang tira ay nagbabanggit pa rin ng patay na index samantalang ang malinis na sagot ay nagbabanggit ng on-link na interface o tamang gateway. Sinasagot iyon ng Find-NetRoute para sa isang address sa isang pagkakataon:
Find-NetRoute -RemoteIPAddress 10.20.4.7Pagkatapos ay subukan ang isang kapitbahay: pumili ng pangalawang prefix na kailangan pa ng split tunnel at kumpirmahin na hindi nagbago ang lookup nito, dahil ang pag-alis ng isang rutang sobra ay ang pagkakamaling inaanyayahan ng paglilinis na ito. Subukan muli ang application na nabigo noong una, at itala kung aling bahagi ang nagmamay-ari ng prefix ngayon. Ang dokumentasyon ng Microsoft para sa Get-NetRoute ay naglilista ng mga field na itinala mo sa ikalawang hakbang. Pagkalipas ng anim na buwan, ang talang iyon ang pumipigil sa parehong entry na masuri nang dalawang beses.