O rută VPN fixată pe un index de interfață se strică la reconectare

Ruta a funcționat săptămâni întregi și apoi a început să trimită trafic nicăieri, cu destinația neschimbată și fără ca nimic să fi fost editat. Ce s-a schimbat este numărul: o rută creată pentru un anumit index de interfață face referire la un adaptor care nu mai există după o reconectare, iar prefixul destinației continuă să indice o infrastructură care a fost înlocuită. Adăugarea persistenței la acea comandă nu ajută, pentru că problema nu a fost niciodată dacă ruta supraviețuiește unei reporniri. Soluția este să legați intenția de conexiune, care prin proiectare supraviețuiește schimbărilor de adaptor.

Verificați spre ce indică ruta de fapt

Începeți prin a citi intrarea de rută și adaptoarele una lângă alta. O rută cu următorul salt pe interfața VPN și un index care nu corespunde niciunui adaptor actual este semnătura acestei defecțiuni; același prefix pe alt index este fie o rămășiță, fie ruta pe care o doriți cu adevărat. Citiți ambele liste înainte de a o modifica pe oricare, pentru că comparația interesantă este între numărul din rută și numerele care există acum. Dacă indexul rutei apare în lista de adaptoare, indexul nu este problema dumneavoastră și căutarea trece la metrici, politică sau capătul îndepărtat. Dacă nu apare, nu mai este nimic de diagnosticat: ruta este legată de o infrastructură care nu mai există.

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

Coloana Store distinge o intrare care persistă între reporniri de una care dispare odată cu adaptorul, iar această diferență decide dacă defecțiunea revine mâine. O intrare în depozitul persistent care indică un index dispărut este cel mai rău caz, pentru că supraviețuiește repornirilor fără să se potrivească vreodată cu ceva.

Legați prefixul de profil, nu de adaptor

Un VPN nativ din Windows poate purta propria listă de rute, astfel încât conexiunea refolosește adaptorul corect ori de câte ori apare. Atunci ruta urmează profilul în locul unui număr pe care l-ați observat o dată, iar niciun script nu trebuie să ghicească un index după fiecare apel. Adăugarea unui prefix este și reversibilă prin comanda de eliminare corespunzătoare, ceea ce menține modificarea auditabilă. Prefixul este stocat împreună cu conexiunea în loc de un script de pornire, așa că un profil copiat la alt utilizator duce intenția cu el.

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

Referința pentru Add-VpnConnectionRoute documentează asocierea cu conexiunea, iar sfera cărții de telefon contează: un profil per utilizator și un profil pentru toți utilizatorii sunt obiecte diferite. Acest mecanism aparține clientului VPN propriu al Windows, așa că un adaptor de la un furnizor administrat de propriul său serviciu poate prelua rutele dintr-o sursă de politică complet diferită.

Curățați rutele vechi înainte de a o adăuga pe cea nouă

Două rute cu același prefix și proprietari diferiți sunt mai rele decât o rută greșită, pentru că învingătorul depinde de metrici pe care nimeni nu le-a notat. Inspectați ce există deja pentru prefix, inclusiv intrările din depozitul persistent, și eliminați doar ce aparține încercării eșuate. O rămășiță dintr-un proiect anterior este obișnuită în acest domeniu, fiindcă ruta care eșuează a înlocuit de obicei ceva ce funcționa. Notați ce intrări aparțin cărei conexiuni înainte de a elimina ceva, și păstrați lista în registrul modificărilor.

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

Potriviți prefix, următorul salt, depozit și proprietar împreună în loc să ștergeți tot ce pare similar. O altă conexiune poate depinde legitim de o parte din acel spațiu, iar o ștergere amplă transformă o reparație ordonată într-un incident de suport.

Reconectați-vă într-o ordine diferită

Reproduceți condiția în loc să sperați că prima încercare a fost reprezentativă. Deconectați, reconectați și confirmați calea selectată către aceeași resursă îndepărtată în timp ce tunelul este activ; cu mai multe VPN-uri în joc, ridicați-le într-o ordine diferită și urmăriți dacă calea aleasă se schimbă. Ordinea este variabila pe care majoritatea o omit, și ea este cea care expune o rută legată de conexiunea greșită.

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

Rezultatul pe care îl doriți nu este ca un adaptor să-și păstreze numărul o dată. Este ca ruta să apară cu orice număr primește conexiunea, de fiecare dată, și să dispară când conexiunea se închide. Reconectarea de două ori este cea mai ieftină cale de a distinge aceste rezultate.

Știți ce nu poate face ruta

O rută de profil oferă o cale și nimic altceva. Nu deschide un firewall îndepărtat, nu creează o rută de întoarcere la capătul îndepărtat și nu rezolvă două locații care folosesc același interval de adrese; fiecare dintre acestea este o configurație separată cu un proprietar separat. Confirmarea căii este deci începutul testului de acceptare, nu tot testul.

Păstrați lista de prefixe lângă profil și notați sub ce sferă a fost adăugat, ca următoarea persoană să poată citi proiectul intenționat în loc să îl deducă dintr-un tabel de rute. Rutele care există doar în memoria cuiva sunt cele care se reconstruiesc greșit după următoarea reconectare. Un comentariu de o linie în notele de implementare costă mai puțin decât o după-amiază întreagă de redescoperire.