Cum distingi rutele împinse de VPN de cele statice în Linux

Un prefix apare pe laptop când tunelul urcă, așa că pare că l-a instalat VPN-ul. Poate că da, dar același rezultat poate veni de la un script de client care rulează la conectare, de la un profil de conexiune care listează subrețeaua sau de la o rută statică ce era acolo de la început și a început să funcționeze abia când interfața a existat. Alegerea proprietarului greșit înseamnă că ruta revine după fiecare curățare, iar următoarea persoană repetă aceeași corecție. Secvența de mai jos separă cele trei înainte de a schimba ceva.

Pasul 1: numește mecanismul care instalează prefixe

Protocoale diferite oferă accesibilitate în moduri diferite, iar numirea tuturor acestora anunț ascunde distincția. Un server OpenVPN împinge o directivă de rută pe canalul de control, iar clientul o instalează dacă un filtru pull nu o blochează. O configurație WireGuard listează local prefixele permise, pe care clientul le folosește atât pentru rutarea cheilor criptografice, cât și pentru rutele pe care le adaugă. Un tunel IPsec negociază selectori de trafic cu partenerul, iar nucleul instalează rute din acei selectori.

Identifică pe care dintre acestea îl folosește tunelul tău înainte de a citi orice tabelă. O rută împinsă la conectare nu este un anunț al unui protocol de rutare și nu promite că prefixul este accesibil în spatele capătului îndepărtat. Notează mecanismul lângă prefix, pentru că el decide unde aparține corecția.

Pasul 2: compară tabela de-a lungul unei conexiuni

Salvează tabela principală cu tunelul coborât, ridică-l, salvează din nou și compară cele două capturi. Tot ce a apărut aparține ciclului de viață al conexiunii, iar tot ce a rămas aparține configurației locale.

Captureaz-o cu ip route show table main > /tmp/route-down.txt, conectează-te și capturează din nou. Fă același lucru pentru ip -6 route dacă site-ul folosește IPv6, pentru că un prefix lipsă acolo produce eșecuri care par fără legătură cu rutarea.

Pasul 3: citește metrica, nu doar prezența

Două intrări pentru același prefix pot coexista, iar nucleul o alege pe cea cu metrica mai mică. O rută statică cu metrica 50 va continua să învingă o rută împinsă la 100 chiar dacă ambele sunt vizibile, de aceea „ruta este acolo” și „traficul o folosește” sunt afirmații diferite.

Întreabă nucleul direct cu ip route get 10.20.5.7 și citește interfața pe care o raportează. Dacă traficul iese prin adaptorul fizic în timp ce o rută a tunelului stă în tabelă, metrica sau lungimea prefixului explică asta, nu clientul VPN. Repetă căutarea pentru un gazdă despre care știi că este în spatele tunelului și pentru una despre care știi că nu este, iar diferența arată dacă împărțirea se comportă cum era intenționat.

Pasul 4: găsește intrările care supraviețuiesc tunelului

Rutele statice supraviețuiesc deconectării prin proiectare, iar de acolo vin intrările învechite. O rută persistentă către o interfață care nu mai există poate înghiți în liniște o subrețea, iar una către un nume de interfață reutilizat poate trimite trafic privat pe ușa greșită după o repornire.

Verifică partea persistentă în locul pe care îl folosește distribuția ta, fie că este o unitate systemd-networkd, un profil NetworkManager sau un script în directorul up al clientului. Corectarea tabelei live cu ip route del ține doar până la următoarea conectare. Tratează acea ștergere ca pe un test al ipotezei, nu ca pe reparația.

Acolo unde capătul îndepărtat oferă acoperirea greșită, ridică problema la operator în loc să filtrezi tot. Renunțarea la toate setările împinse aruncă și DNS-ul și politica de tunel divizat de care depinde profilul.

Pasul 5: confirmă calea de întoarcere înainte de a da vina pe client

Pentru o conexiune site-la-site sau o subrețea din spatele tunelului, partea îndepărtată are nevoie de o rută înapoi la adresa clientului tău și de redirecționare activată pe gateway. O cale cu un singur sens arată exact ca un defect de rutare al clientului, doar că strângerea de mână și pachetul de ieșire reușesc amândouă.

Filtrarea căii inverse adaugă o a doua capcană pe gateway-urile Linux. Un răspuns care sosește pe o interfață diferită de cea prevăzută de rută este aruncat în modul strict, iar căile asimetrice prin doi furnizori declanșează asta în mod fiabil. Contoarele de eliminare de pe gateway, nu de pe client, îți spun dacă filtrarea este cauza.

Pasul 6: testează resursa, nu pingul

După ce ruta aleasă este corectă, deschide resursa reală și confirmă traficul de întoarcere. Un răspuns la ping dovedește calea într-o singură direcție și nimic despre serviciu, iar un serviciu care răspunde pe o conexiune din cache dovedește și mai puțin.

Apoi repetă întreaga verificare după o reconectare. Valoarea secvenței este că prezice ce va face următoarea conectare, de aceea atât comparația, cât și metrica aparțin tichetului.