Saskarnes indeksam piesaistīts VPN maršruts sabrūk atkārtoti pieslēdzoties

Maršruts, kas piesaistīts adaptera numuram, iet bojā, kad šis numurs mainās. Pārbaudiet krātuvi, piesaistiet prefiksu profilam un pēc tam atkārtoti pieslēdzieties jaunā secībā.

Maršruts darbojās nedēļām, un tad sāka sūtīt datplūsmu nekurp, kamēr galamērķis palika nemainīgs un nekas netika rediģēts. Tas, kas mainījās, ir numurs: maršruts, kas izveidots konkrētam saskarnes indeksam, norāda uz adapteri, kura pēc atkārtotas pieslēgšanās vairs nav, un galamērķa prefikss turpina norādīt uz nomainīto infrastruktūru. Noturības pievienošana šai komandai nepalīdz, jo problēma nekad nebija tā, vai maršruts pārdzīvo pārstartēšanu. Risinājums ir piesaistīt nodomu savienojumam, kas pēc konstrukcijas pārdzīvo adapteru maiņu.

Pārbaudiet, uz ko maršruts patiešām norāda

Sāciet, lasot maršruta ierakstu un adapterus blakus. Maršruts ar nākamo lēcienu uz VPN saskarnes un indeksu, kas neatbilst nevienam pašreizējam adapterim, ir šī defekta paraksts; tas pats prefikss citā indeksā ir vai nu pārpalikums, vai maršruts, kuru jūs patiešām vēlaties. Izlasiet abus sarakstus pirms jebkura mainīšanas, jo interesantais salīdzinājums ir starp numuru maršrutā un numuriem, kas pastāv tagad. Ja maršruta indekss parādās adapteru sarakstā, indekss nav jūsu problēma un meklēšana pāriet uz metriku, politiku vai tālo galu. Ja tas neparādās, vairs nekas nav jādiagnosticē: maršruts ir piesaistīts infrastruktūrai, kuras vairs nav.

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

Kolonna Store atšķir ierakstu, kas saglabājas starp pārstartēšanām, no ieraksta, kas pazūd kopā ar adapteri, un šī atšķirība nosaka, vai defekts atgriezīsies rīt. Ieraksts pastāvīgajā krātuvē, kas norāda uz pazudušo indeksu, ir sliktākais gadījums, jo tas pārdzīvo pārstartēšanas, bet nekad nesakrīt ar neko.

Piesaistiet prefiksu profilam, nevis adapterim

Windows iebūvētais VPN var nest savu maršrutu sarakstu, tāpēc savienojums atkalizmanto pareizo adapteri ikreiz, kad tas parādās. Tad maršruts seko profilam, nevis numuram, ko vienreiz novērojāt, un nevienam skriptam pēc katra zvana nav jāuzmin indekss. Prefiksa pievienošana ir arī atgriezeniska ar atbilstošo noņemšanas komandu, kas saglabā izmaiņas auditējamu. Prefikss tiek saglabāts kopā ar savienojumu, nevis palaišanas skriptā, tāpēc citam lietotājam kopēts profils nes nodomu līdzi.

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

Add-VpnConnectionRoute atsauce dokumentē saistību ar savienojumu, un tālruņu grāmatas apjoms ir svarīgs: profils vienam lietotājam un profils visiem lietotājiem ir atšķirīgi objekti. Šis mehānisms pieder pašam Windows VPN klientam, tāpēc piegādātāja adapteris, ko pārvalda tā paša pakalpojums, var ņemt savus maršrutus no pavisam cita politikas avota.

Notīriet vecos maršrutus pirms jaunā pievienošanas

Divi maršruti ar vienu un to pašu prefiksu un dažādiem īpašniekiem ir sliktāk nekā viens nepareizs maršruts, jo uzvarētājs ir atkarīgs no metrikiem, kurus neviens nav pierakstījis. Apskatiet, kas prefiksam jau pastāv, tostarp ierakstus pastāvīgajā krātuvē, un noņemiet tikai to, kas pieder neizdevušajam mēģinājumam. Iepriekšēja dizaina pārpalikums šajā jomā ir ierasts, jo nespējīgais maršruts parasti aizstāja kaut ko, kas strādāja. Pirms kaut ko noņemat, pierakstiet, kuri ieraksti pieder kuram savienojumam, un sarakstu glabājiet izmaiņu žurnālā.

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

Saskaņojiet prefiksu, nākamo lēcienu, krātuvi un īpašnieku kopā, nevis dzēsiet visu, kas izskatās līdzīgi. Cits savienojums var likumīgi būt atkarīgs no daļas šīs telpas, un plaša dzēšana pārvērš kārtīgu remontu atbalsta incidentā.

Atkārtoti pieslēdzieties citā secībā

Reproducējiet nosacījumu, nevis ceriet, ka pirmais mēģinājums bija reprezentatīvs. Atvienojieties, pieslēdzieties atkārtoti un apstipriniet izvēlēto ceļu uz to pašu attālo resursu, kamēr tunelis ir augšā; ja spēlē ir vairāki VPN, paceliet tos citā secībā un vērojiet, vai izvēlētais ceļš mainās. Secība ir mainīgais, ko vairums izlaiž, un tieši tā atklāj maršrutu, kas piesaistīts nepareizajam savienojumam.

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

Rezultāts, ko vēlaties, nav tas, ka adapteris vienreiz patur savu numuru. Tas ir, ka maršruts parādās ar jebkuru numuru, ko savienojums saņem, katru reizi, un pazūd, kad savienojums aizveras. Divreiz pieslēgties atkārtoti ir lētākais veids, kā šos rezultātus atšķirt.

Ziniet, ko maršruts nevar

Profila maršruts nodrošina ceļu un neko citu. Tas neatver attālināto ugunsmūri, neizveido atgriešanās maršrutu tālajā galā un neatrisina divas vietas, kas izmanto vienu un to pašu adrešu diapazonu; katrs no tiem ir atsevišķa konfigurācija ar atsevišķu īpašnieku. Tāpēc ceļa apstiprināšana ir pieņemšanas testa sākums, nevis viss tests.

Glabājiet prefiksu sarakstu kopā ar profilu un pierakstiet, kādā apjomā tas tika pievienots, lai nākamais cilvēks varētu izlasīt paredzēto dizainu, nevis secināt to no maršrutu tabulas. Maršruti, kas pastāv tikai kāda atmiņā, ir tie, kas pēc nākamās atkārtotās pieslēgšanās tiek nepareizi atjaunoti. Vienas rindas komentārs izvietošanas piezīmēs maksā mazāk nekā vesela pēcpusdiena atkalatklāšanas.

Saistītie raksti