De ce o subrețea ocolește în continuare ruta implicită a VPN-ului

Comutați VPN-ul pe tunel complet, majoritatea traficului ascultă, iar apoi o adresă răspunde direct — o imprimantă, un NAS, un host de salt la 10.x. Interpretarea evidentă este că tunelul pierde, așa că scădeți metrica pe ruta implicită și nimic nu se schimbă. Acea încercare eșuată este indiciul: o rută implicită este o rezervă, nu o sentință. Căutarea rutei ia cel mai lung prefix potrivit înainte de a compara vreodată metrici, așa că un /24 continuă să câștige împotriva unui /0, indiferent ce număr atașați la oricare dintre ele. Odată ce această ordine este clară, scurgerea este de obicei o rută pe care cineva a instalat-o intenționat, sau un prefix pe care clientul nu a intenționat niciodată să îl acopere.

Ce promite de fapt o rută implicită

0.0.0.0/0 se potrivește cu orice destinație IPv4 cu zero biți de specificitate. Există pentru ca un host să ajungă la orice tabelul său nu descrie mai bine. O rută către 192.168.1.0/24 poartă 24 de biți potriviți, așa că pentru 192.168.1.40 câștigă înainte ca cineva să compare metrici, distanță administrativă sau cum numește clientul câmpul său de prioritate. Aceeași regulă este valabilă în FIB-ul Linux, în tabelul de rutare Windows și în stiva BSD din spatele macOS.

Într-o LAN normală acel comportament este o funcție. Subrețeaua locală este conectată direct, imprimanta continuă să funcționeze în timp ce tunelul transportă navigarea, și nimic nu este configurat greșit. Întrebarea care merită pusă nu este de ce acea adresă merge direct, ci ce prefix din ce tabel se potrivește cu ea, și cine l-a pus acolo.

Semi-rute implicite, sau de ce intrarea implicită poate părea neatinsă

Cel mai curat exemplu este redirect-gateway def1 din OpenVPN. În loc să șteargă ruta implicită și să o înlocuiască, adaugă 0.0.0.0/1 și 128.0.0.0/1. Împreună, perechea acoperă tot IPv4, fiecare prefix este mai lung decât /0, și ambele bat ruta implicită a routerului lăsând-o pe loc. Rulați o listă de rute după aceea și ruta implicită originală este încă acolo, încă indică gateway-ul dvs.; pur și simplu nu este niciodată selectată pentru destinații de internet.

wg-quick din WireGuard ajunge la același rezultat prin rutare bazată pe politică. Când AllowedIPs acoperă 0.0.0.0/0, creează propriul tabel, trimite pachetele marcate acolo și adaugă o regulă care ignoră prefixul de lungime zero al tabelului principal. Tabelul principal își păstrează intrarea implicită, iar regulile decid că tabelul tunelului este consultat primul pentru traficul pe care interfața îl deține.

Ambele designe au nevoie de exact o rută în afara tunelului: o rută de host către adresa serverului VPN prin gateway-ul original. Fără ea, clientul ar încerca să transporte pachetele care construiesc tunelul în interiorul tunelului, iar conexiunea nu s-ar finaliza niciodată. O rută care nu este de tunel în tabelul dvs. este deci normală chiar și pe un profil strict de tunel complet. Rutele care merită contestate sunt cele care acoperă destinații care vă pasă cu adevărat.

Metricile decid egalități, prefixele decid câștigători

Metricile sunt comparate doar între candidați care se potrivesc la fel de bine cu destinația. Pe Linux ip route get 10.20.5.9 afișează câștigătorul împreună cu tabelul său, iar ip route show table all listează candidații, inclusiv orice semi-rute implicite și orice tabel către care indică o regulă. Pe Windows Find-NetRoute -RemoteIPAddress 10.20.5.9 returnează ruta selectată și adresa sursă, în timp ce Get-NetRoute arată tabelul brut — dar costul efectiv este metrica rutei plus metrica interfeței, așa că un adaptor lent poate pierde o egalitate pe care pare să o câștige.

Trei cazuri acoperă cea mai mare parte din ce veți vedea:

• Aceeași destinație, /24 contra /0: /24 câștigă la lungimea prefixului, orice ar spune metricile.
• Aceeași destinație, două /24 cu metrici diferite: câștigă metrica efectivă mai mică.
• Aceeași destinație, două tabele, unul ales de o regulă de politică: regula alege întâi tabelul, iar comparația prefixelor are loc în el.

Al treilea caz este locul unde se termină majoritatea acestor rapoarte. O ip rule din Linux sau un filtru de trafic VPN din Windows poate trimite trafic către un tabel care nu a conținut niciodată ruta implicită a tunelului, iar tabelul principal arată perfect tot timpul.

Cine deține de obicei ocolirea

Începeți cu profilul, nu cu tabelul. Configurațiile split-tunnel și setările VPN per aplicație lasă în mod deliberat prefixe numite în afara tunelului; un profil de lucru care protejează o subrețea privată și lasă navigarea generală să meargă direct se comportă conform proiectării, iar suprascrierea lui încalcă politica pe care trebuia să o impună. Ghidul de rutare VPN al Microsoft trasează aceeași linie între traficul forțat în tunel și excepțiile explicite, ceea ce îl face o verificare încrucișată utilă înainte de a edita ceva.

Apoi căutați resturi. O rută care indică o interfață care nu mai există, sau o adresă din rețeaua anterioară, apare după ce stațiile de andocare, adaptoarele USB și podurile pentru containere vin și pleacă. Ștergerea o dată nu este sfârșitul: profilurile de conexiune NetworkManager, fișierele netplan și rutele persistente Windows o reinstalează la următoarea conectare sau pornire, așa că găsiți fișierul sau profilul care o deține înainte de a edita ceva.

Apoi verificați IPv6 separat. ip -6 route și Get-NetRoute -AddressFamily IPv6 păstrează stare separată, rute implicite separate și comportament de client separat. Un audit doar IPv4 nu spune nimic despre un host cu stivă dublă care preferă în liniște o cale IPv6 nativă, iar asta singur poate face un client să pară split-tunnel.

Confirmați cu fluxul aplicației înseși

Notați destinația pe care aplicația o folosește efectiv, apoi întrebați sistemul despre calea pe care ar lua-o de la adresa sursă la care se leagă acea aplicație. ip route get 10.20.5.9 from 192.168.1.40 răspunde la asta pe Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 plus adresa locală face asta pe Windows. Comparați rezultatul cu ce afirmă profilul. Pagina de IP public a unui browser testează o destinație pe un protocol și nu spune nimic despre adresa privată care a început reclamația.

Remediați cel mai îngust obiect care explică diferența. Dacă excepția este aprobată, notați prefixul și lăsați-l; dacă nu, eliminați ruta sau adăugați o rută explicită mai îngustă prin tunel în loc să coborâți metrica rutei implicite. Coborârea unei metrici nu poate depăși un prefix mai lung, iar editarea rutei implicite în timp ce două rute /1 dețin calea de internet nici nu schimbă nimic.

Apoi reconectați tunelul și repetați aceeași interogare. Clienții reinstalează rute la fiecare conectare, deci o modificare care rezistă doar până la următorul handshake nu a fost testată. Dacă calea încă divergează, suspecții rămași sunt o regulă de politică, un al doilea tabel sau un filtru pe partea clientului — nu ruta implicită.

• Numiți destinația și adresa sursă pe care aplicația le folosește efectiv.
• Afișați ruta câștigătoare cu ip route get sau Find-NetRoute.
• Verificați dacă o pereche /1 sau un tabel de politică deține calea de internet.
• Listați fiecare prefix mai lung decât /0 care corespunde destinației.
• Repetați verificarea IPv6 separat.
• Urmăriți ruta supraviețuitoare înapoi la fișierul, profilul sau filtrul care o instalează.
• Reconectați și rulați din nou interogarea înainte de a o declara rezolvată.

Dacă toate șapte sunt de acord cu profilul, tunelul face exact ce a fost configurat să facă, iar remedierea aparține profilului, nu unei metrici.