Métrica rutei VPN s-a schimbat după conectare: ce înseamnă
O metrică mai mică doar departajează rutele la fel de specifice. Citiți regula de politică, prefixul și ruta de gazdă a punctului final înainte de a modifica orice număr de rută VPN.
Vă conectați la VPN, rulați route print, iar ruta implicită are acum o metrică mult mai mică decât înainte. Concluzia naturală este că VPN-ul a preluat ruta implicită pentru că numărul ei este mai mic. Uneori exact asta s-a întâmplat. De multe ori metrica nu este deloc factorul decisiv, iar modificarea ei nu schimbă nimic pentru că alegerea a fost făcută mai devreme, de lungimea prefixului sau de o regulă de politică.
Simptomul este real: traficul care înainte ieșea prin adaptorul Wi-Fi iese acum prin tunel, sau invers. Metrica este o singură intrare într-o căutare care rulează într-o ordine fixă, iar acea ordine este ce trebuie citit înainte de a atinge un număr.
Cu ce concurează de fapt numărul
Prima comparație este specificitatea, nu preferința. O rută pentru 10.20.0.0/16 bate 10.0.0.0/8, iar ambele bat 0.0.0.0/0, orice ar spune metricele lor. Un VPN care instalează o rută implicită cu cea mai mică metrică de pe mașină pierde totuși în fața oricărei rute mai specifice care se potrivește destinației, inclusiv ruta de gazdă pe care clientul o instalează pentru propriul server.
De aceea scăderea metricii pe o rută implicită nu poate forța o subrețea conectată direct în tunel. Dacă vreți acea subrețea în interiorul VPN-ului, adăugați o rută pentru prefix sau selectați tabelul tunelului cu o regulă de politică. Metrica este pârghia greșită pentru această sarcină.
| Check in this order | Question | Where you read it |
|---|---|---|
| 1. Policy and table | Which routing table does this traffic use? | ip rule, client profile |
| 2. Prefix length | Which matching route is most specific? | route print, ip route |
| 3. Metric | Which of the equally specific routes is preferred? | route print, ip route |
| 4. Interface state | Is the chosen next hop reachable? | adapter status, link state |
Linux decide tabelul înainte de metrică
Pe Linux nucleul consultă mai întâi baza de politici. ip rule listează regulile și tabelele pe care le selectează, iar ip route get 203.0.113.10 raportează tabelul, ruta și adresa sursă pe care nucleul le-ar folosi efectiv pentru acea destinație. O metrică din interiorul tabelului 100 nu concurează niciodată cu o rută din tabelul principal, pentru că regula a ales tabelul înainte de a fi comparată vreo metrică.
De aceea o rută poate părea corectă în ip route show table all și totuși să nu transporte trafic. Citiți regula care s-a potrivit, apoi tabelul pe care l-a selectat, apoi comparați rutele din interiorul tabelului. Dacă a fost selectat tabelul greșit, nicio modificare a metricii în celălalt tabel nu va ajuta.
Windows combină două metrice
Windows nu are o bază de politici implicită, dar combină o metrică de rută cu o metrică de interfață, iar metrica automată a interfeței se poate schimba cu viteza legăturii și starea adaptorului. De aceea aceeași rută se poate comporta diferit după ce apare o stație de andocare sau un adaptor virtual. Find-NetRoute -RemoteIPAddress 203.0.113.10 raportează adresa sursă, următorul salt și interfața alese, ceea ce este mai aproape de decizia reală decât tabelul brut.
Citiți împreună valorile rutei și ale interfeței. Creșterea metricii unei interfețe poate muta traficul fără ca vreo intrare de rută să se schimbe, iar un client VPN care își deține rutele le va reinstala la reconectare și va arunca modificarea dumneavoastră.
Țineți punctul final al tunelului în afara tunelului
Fiecare tunel are nevoie de o cale către propriul server care nu trece prin tunel. Clienții instalează o rută de gazdă pentru punctul final prin gateway-ul fizic, iar acea rută trebuie să rămână mai specifică decât ruta implicită pe care o adaugă clientul. Ștergeți-o, sau lăsați tunelul să câștige căutarea pentru acea adresă, iar pachetele încapsulate vor încerca să intre în tunelul pe care ar trebui să îl construiască. Conexiunea eșuează sau intră în buclă.
Verificați acea rută de gazdă înainte și după orice modificare a metricii: trebuie să indice următorul salt fizic și să supraviețuiască unei reconectări. Dacă clientul o deține, modificați profilul sau configurația administrată în locul unei valori de runtime care va fi suprascrisă.
Verificați ambele familii de adrese și contextul aplicației
IPv4 și IPv6 sunt decizii separate cu tabele separate. Un VPN poate transporta IPv4 în timp ce IPv6 continuă să folosească routerul local, iar o modificare de metrică într-o familie nu spune nimic despre cealaltă. Verificați ambele, apoi verificați contextul aplicației. Un proces legat de o interfață, un namespace de container sau un VPN per aplicație poate vedea alt tabel decât shell-ul dumneavoastră.
Verificați cu instrumentul care raportează decizia pentru destinația reală, nu cu listarea completă a tabelului. Dacă ruta aleasă este cea pe care o prevede designul, opriți-vă. O metrică ce nu este cel mai mic număr de pe ecran nu este un defect, iar forțarea ei să fie cea mai mică poate rupe calea punctului final de care depinde tunelul.