Egy felületindexhez rögzített VPN-útvonal elromlik újracsatlakozáskor

Az útvonal hetekig működött, majd elkezdett forgalmat sehová küldeni, miközben a cél változatlan maradt és semmit nem szerkesztettek. Ami megváltozott, az a szám: az adott felületindexhez létrehozott útvonal olyan adapterre hivatkozik, amely újracsatlakozás után már nem létezik, a cél-előtag pedig továbbra is a lecserélt infrastruktúrára mutat. Nem segít, ha tartósságot adunk ehhez a parancshoz, mert a probléma soha nem az volt, hogy túléli-e az útvonal az újraindítást. A megoldás az, hogy a szándékot a kapcsolathoz kötjük, amely tervezésénél fogva túléli az adaptercseréket.

Ellenőrizze, mire mutat valójában az útvonal

Kezdje az útvonal-bejegyzés és az adapterek egymás melletti olvasásával. Az olyan útvonal, amelynek következő ugrása a VPN-felületen van, és indexe egyetlen jelenlegi adapterhez sem illik, ennek a hibának a jellemzője; ugyanaz az előtag másik indexen vagy maradvány, vagy az az útvonal, amelyet valóban szeretne. Olvassa el mindkét listát, mielőtt bármelyiket módosítaná, mert az érdekes összehasonlítás az útvonalban lévő szám és a jelenleg létező számok között van. Ha az útvonal indexe szerepel az adapterlistában, az index nem az ön problémája, és a keresés mérőszámokra, házirendre vagy a távoli végpontra terelődik. Ha nem szerepel, semmit nem kell tovább diagnosztizálni: az útvonal olyan infrastruktúrához kapcsolódik, amely már nem létezik.

Get-NetRoute -DestinationPrefix '10.77.0.0/16' | Select-Object DestinationPrefix, NextHop, InterfaceIndex, Store
Get-NetAdapter | Where-Object InterfaceDescription -like '*VPN*' | Select-Object Name, InterfaceIndex, InterfaceDescription
Get-VpnConnection -Name 'Lab VPN' | Select-Object Name, ServerAddress, SplitTunneling

A Store oszlop megkülönbözteti az újraindításokat túlélő bejegyzést az adapterrel eltűnő bejegyzéstől, és ez a különbség dönti el, hogy visszatér-e a hiba holnap. A tartós tárolóban lévő, eltűnt indexre mutató bejegyzés a legrosszabb eset, mert túléli az újraindításokat, miközben soha semmihez nem illik.

Az előtagot a profilhoz kösse, ne az adapterhez

A natív Windows VPN saját útvonallistát hordozhat, így a kapcsolat újra a megfelelő adaptert használja, valahányszor feljön. Ekkor az útvonal a profilt követi egy egyszer látott szám helyett, és egyetlen szkriptnek sem kell indexet kitalálnia minden tárcsázás után. Az előtag hozzáadása a megfelelő eltávolító parancson keresztül visszafordítható is, ami a változtatást ellenőrizhetővé teszi. Az előtag a kapcsolattal együtt tárolódik, nem indítási szkriptben, így a más felhasználóhoz másolt profil magával viszi a szándékot.

Add-VpnConnectionRoute -ConnectionName 'Lab VPN' -DestinationPrefix '10.77.0.0/16' -PassThru

Az Add-VpnConnectionRoute referenciája dokumentálja a kapcsolathoz rendelést, és a telefonkönyv hatóköre számít: a felhasználónkénti profil és a minden felhasználóra érvényes profil különböző objektumok. Ez a mechanizmus a Windows saját VPN-klienséhez tartozik, ezért egy saját szolgáltatása által kezelt szállítói adapter teljesen más házirend-forrásból veheti az útvonalait.

Az új hozzáadása előtt tisztítsa meg a régi útvonalakat

Két azonos előtagú, különböző tulajdonosú útvonal rosszabb egyetlen hibás útvonalnál, mert a győztes olyan mérőszámoktól függ, amelyeket senki nem jegyzett fel. Vizsgálja meg, mi létezik már az előtaghoz, beleértve a tartós tároló bejegyzéseit, és csak azt távolítsa el, ami a sikertelen kísérlethez tartozik. Az előző tervezésből maradt darab gyakori ezen a területen, mert a meghibásodó útvonal általában valami működőt váltott fel. Mielőtt bármit eltávolít, jegyezze fel, mely bejegyzések melyik kapcsolathoz tartoznak, és tartsa a listát a változási nyilvántartásban.

Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like '10.77.*'
Remove-NetRoute -DestinationPrefix '10.77.0.0/16' -NextHop '0.0.0.0' -Confirm:$false

Az előtagot, a következő ugrást, a tárolót és a tulajdonost együtt egyeztesse, ahelyett hogy mindent törölne, ami hasonlónak tűnik. Egy másik kapcsolat jogosan függhet a tér egy részétől, és a mindent elsöprő törlés egy rendes javítást támogatási esetté változtat.

Csatlakozzon újra más sorrendben

Reprodukálja a feltételt, ahelyett hogy remélné, az első kísérlet reprezentatív volt. Szakítsa meg, csatlakozzon újra, és erősítse meg a kiválasztott utat ugyanahhoz a távoli erőforráshoz, amíg az alagút él; ha több VPN van játékban, más sorrendben hozza fel őket, és figyelje, változik-e a kiválasztott út. A sorrend az a változó, amelyet a legtöbben kihagynak, és ez az, amely leleplezi a rossz kapcsolathoz kötött útvonalat.

rasdial 'Lab VPN' /disconnect
rasdial 'Lab VPN'
Find-NetRoute -RemoteIPAddress 10.77.5.20 | Select-Object -First 1

A kívánt eredmény nem az, hogy az adapter egyszer megtartja a számát. Hanem az, hogy az útvonal minden alkalommal azzal a számmal jelenjen meg, amelyet a kapcsolat kap, és eltűnjön, amikor a kapcsolat bezárul. Kétszer újracsatlakozni a legolcsóbb módja ezeknek az eredményeknek az elkülönítésére.

Tudja, mit nem tud az útvonal

A profilútvonal utat ad, és semmi mást. Nem nyit távoli tűzfalat, nem hoz létre visszaútvonalat a távoli végponton, és nem old meg két olyan telephelyet, amely ugyanazt a címtartományt használja; ezek mindegyike külön konfiguráció külön tulajdonossal. Az út megerősítése ezért az átvételi teszt kezdete, nem a teljes teszt.

Tartsa az előtaglistát a profilnál, és jegyezze fel, milyen hatókörben lett hozzáadva, hogy a következő ember elolvashassa a tervezett kialakítást, ahelyett hogy útvonaltáblából következtetné ki. Csak valaki emlékezetében létező útvonalak azok, amelyeket a következő újracsatlakozás után hibásan építenek újra. Egy egysoros megjegyzés az üzembe helyezési jegyzetekben kevesebbe kerül, mint egy egész délután újrafelfedezése.