OpenVPN redirect-gateway: ce face fiecare flag cu rutele

Conectați-vă cu redirect-gateway în profil, iar ruta implicită a mașinii poate dispărea, se poate împărți în două sau poate rămâne exact unde era, în funcție de flaguri pe care nimeni nu le citește de două ori. Opțiunea schimbă doar starea de rutare și nimic altceva, așa că singura dovadă de încredere a ceea ce a făcut este tabelul pe care clientul l-a instalat după aceea. Urmează tabelul după o conexiune, ruta care ține în viață tunelul însuși și traficul IPv6 pe care directiva nu pretinde niciodată că îl acoperă. Fiecare pas este o comandă pe care o puteți rula pe client cât timp tunelul este activ.

Ce face fiecare flag cu ruta implicită

Fără niciun flag, opțiunea elimină ruta implicită obișnuită și pune tunelul în locul ei, așa că vechea poartă dispare din tabel cât timp conexiunea este activă. Adăugați def1 și acea rută implicită rămâne listată, iar două rute mai înguste fac treaba. Adăugați bypass-dhcp și ruta DHCP supraviețuiește și ea, ceea ce contează într-o rețea în care clientul trebuie încă să ajungă la serverul DHCP local. Lista de flaguri de pe pagina manualului OpenVPN 2.6 este destul de scurtă pentru o singură citire, iar fiecare intrare schimbă ce rute ajung în tabel.

O opțiune împinsă se comportă la fel când ajunge, așa că profilul clientului poate să nu conțină nimic în timp ce tabelul pare complet redirectat. Este normal: serverul a trimis flagurile, clientul le-a aplicat, iar fișierul local nu a menționat niciodată directiva. Când o împingere pare să nu facă nimic, verificați filtrul din partea clientului care acceptă sau aruncă opțiunile trase, pentru că o opțiune aruncată nu generează eroare pe niciuna dintre părți.

def1 câștigă prin specificitate fără să atingă ruta implicită

Două rute semi-implicite acoperă împreună spațiul IPv4, 0.0.0.0/1 și 128.0.0.0/1. Fiecare este mai specifică decât 0.0.0.0/0, așa că o căutare le preferă în timp ce ruta implicită reală rămâne în tabel pentru tot ce cere potrivirea cea mai puțin specifică.

Citiți tabelul, nu profilul, pentru că doar tabelul arată în care dintre aceste cazuri vă aflați. Două linii sunt suficiente pentru a le distinge:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Observați interfața și metrica pe fiecare linie, nu doar destinația. O rută implicită care indică tunelul și o pereche de semi-implicite care indică tunelul descriu aceeași intenție și eșuează diferit când tunelul cade, pentru că într-un caz ruta de rezervă încă există. Notați ambele câmpuri în nota de modificare. O rută de rezervă supraviețuitoare este uneori cea care ține o sesiune la distanță în viață suficient de mult pentru a repara tunelul, și tot ea este cea care scurge trafic când intenția era un tunel complet.

Păstrați accesibil capătul tunelului

Clientul are nevoie de o rută către capătul îndepărtat al tunelului care nu trece ea însăși prin tunel. OpenVPN instalează acea rută de gazdă înainte de a schimba orice altceva, iar o editare manuală a rutelor sau un al doilea client VPN o pot elimina. Simptomul de după este o conexiune care raportează că este conectată și apoi nu lasă nimic să treacă.

Întrebați nucleul ce interfață ar folosi pentru adresa capătului cât timp tunelul este activ. Răspunsul trebuie să numească interfața fizică și poarta acesteia, niciodată tun0:

ip route get 198.51.100.20

Dacă acea căutare returnează dispozitivul tunelului, tunelul își transportă propriul trafic și se va prăbuși de îndată ce un pachet trebuie să iasă. Prefixele locale, un al doilea adaptor și rutarea bazată pe politici contează în continuare aici, de aceea o redirecționare care funcționează pe un laptop curat poate eșua pe o gazdă cu interfață de administrare și două rute implicite. De obicei profilul este vinovat pentru ce a făcut planul de adrese.

Traficul IPv6 continuă să folosească propriul tabel

Redirecționarea IPv4 lasă IPv6 în pace, iar cele două familii sunt schimbate de flaguri diferite. Pe o gazdă cu stivă dublă și o rută implicită v6 funcțională, traficul v4 poate sta complet în interiorul tunelului în timp ce fiecare destinație capabilă de v6 iese prin legătura fizică. O gazdă care pare corectă într-un tabel scurge în celălalt.

Verificați tabelul v6 după conectare în loc să presupuneți că tunelul l-a acoperit. Directiva poartă flaguri de familie de adrese exact din acest motiv, iar un profil care le omite moștenește ce face platforma implicit:

ip -6 route show default
ip -6 route get 2001:db8::10

Dovediți ce interfață folosește o aplicație

O stare conectată nu este un blocaj, iar o schimbare de rută nu este un întrerupător de urgență. Dacă traficul direct trebuie să se oprească atunci când tunelul eșuează, acea politică trăiește în firewall și are nevoie de propriul test.

Testați calea pe care o aplicație o urmează cu adevărat, nu calea pe care o descrie profilul. Cereți mai întâi ruta, apoi legați o cerere la fiecare interfață pe rând și comparați ce raportează partea îndepărtată:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Dacă ambele cereri returnează aceeași adresă, aplicația nu folosește tunelul, deși tabelul de rutare spune că ar trebui. Dacă reușește doar cererea legată de tunel, calea fizică este filtrată pentru acea destinație și tunelul face ce ați cerut. Scrieți flagurile, rutele instalate, căutarea capătului și ambele rezultate de ieșire în jurnalul de modificări, ca următoarea persoană să moștenească fapte în loc de o captură de ecran.