Tabela de rutare versus căutarea reală: unde ajunge traficul VPN

O descărcare a tabelului de rutare este cel mai puțin util diagnostic în depanarea VPN și cel mai des lipit. Patruzeci de linii de prefixe vă spun ce ar putea face mașina, nu ce a făcut pentru cererea care a eșuat. Mecanismul pe care îl doriți de fapt este căutarea: date fiind această sursă și această destinație, ce regulă s-a potrivit, ce tabelă a fost consultată și ce interfață și următorul salt au ieșit. Începeți cu o destinație și o sursă, apoi citiți tabelul cu întrebarea respectivă în mână, și aceeași ieșire devine dovadă în loc de zgomot.

O tabelă este un set de candidați, nu o decizie

Fiecare intrare descrie un prefix și ce trebuie făcut cu traficul care i se potrivește: trimite-l la o interfață, predă-l unui salt următor sau aruncă-l. Nimic din acea listă nu este ordonat după intenție, iar intrarea care pare cea mai specifică unui om nu este întotdeauna cea pe care o selectează nucleul, pentru că selecția urmează cea mai lungă potrivire de prefix și, între prefixe egale, metrica.

Deci primul pas este să întrebați nucleul în loc să citiți lista. Comanda de căutare răspunde pentru o destinație, iar cu un argument de sursă răspunde pentru perechea exactă pe care ar folosi-o o conexiune redirecționată sau legată:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Fiecare adresă de mai sus este un exemplu de documentație. Ideea este forma răspunsului: interfață, adresă de sursă aleasă, gateway și tabelul din care a venit intrarea. Dacă acea ieșire nu corespunde interfeței pe care o așteptați, ați localizat problema cu o singură comandă, și nicio cantitate de citire a tabelului complet nu v-ar fi spus care candidat a câștigat.

Căutarea trece mai întâi prin reguli, apoi prin tabele

Pe Linux decizia este în două etape. Regulile de politică sunt evaluate în ordinea priorității, iar prima regulă care se potrivește numește o tabelă de consultat; acea tabelă face apoi potrivirea celui mai lung prefix. O regulă poate potrivi pe sursă, destinație, marcă de firewall, interfață sau o combinație, motiv pentru care o descărcare a tabelului principal poate fi perfect exactă și complet irelevantă pentru pachetul pe care îl investigați.

ip rule show
ip route show table all | head -40
ip route show table 100

Dacă o regulă trimite trafic din pool-ul dvs. VPN în tabela 100, atunci tabela 100 este cea care contează, și tabelul principal este o momeală. Acesta este și mecanismul din spatele rutării bazate pe sursă pe un router: aceeași destinație poate avea două răspunsuri diferite în funcție de unde a venit pachetul, și numai căutarea cu un argument de sursă dezvăluie care se aplică.

IPv6 are propriile reguli și tabele. Un design care rulează ambele familii are nevoie de ambele căutări, iar un răspuns IPv4 funcțional nu spune nimic despre calea v6 pe care un client cu stivă dublă ar putea-o prefera.

Ce instalează clientul VPN

Clienții de obicei nu înlocuiesc ruta implicită, pentru că asta ar rupe propria cale exterioară a tunelului. Instalează ceva mai specific care câștigă prin lungimea prefixului: o pereche de jumătăți de rută implicită care acoperă 0.0.0.0/1 și 128.0.0.0/1 este trucul clasic, deoarece ambele sunt prefixe mai lungi decât 0.0.0.0/0 și împreună acoperă tot spațiul. Alții instalează prefixe private specifice plus o regulă de politică, iar unii adaugă o marcă pentru ca doar traficul selectat să fie capturat.

De aceea "VPN-ul nu mi-a schimbat ruta implicită" nu este dovadă de eșec. Verificați ce a adăugat de fapt, și dacă destinația în cauză se află în interiorul acelor prefixe:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Două jumătăți de rută sunt ușor de ratat într-o descărcare pentru că nu arată ca o rută implicită. O configurație split-tunnel care a uitat să includă un prefix produce exact simptomul pe care îl urmăriți: aplicația care ar trebui să folosească tunelul rezolvă și se conectează local în schimb. Comparați prefixele instalate cu destinațiile de care utilizatorul are nevoie cu adevărat, nu cu adresele pe care le-ați testat din întâmplare. O listă split-tunnel care acoperă serverul de fișiere dar nu rezolvatorul său produce o conexiune care se rezolvă la o adresă publică și apoi eșuează autentificarea, ceea ce pare o problemă de parolă și este o problemă de rută.

Și ruta exterioară trebuie să supraviețuiască

Tunelul este el însuși trafic. Pachetele care transportă încărcătura încapsulată merg la adresa peer-ului prin interfața fizică, iar acea cale nu trebuie rutată înapoi în tunel. Când este, obțineți eșecul caracteristic în care tunelul se stabilește și apoi nu mai lasă traficul să treacă, pentru că transportul tunelului este acum în interiorul tunelului.

Verificați adresa peer-ului așa cum ați verificat destinația interioară, și confirmați că se rezolvă la interfața fizică și nu la tunel:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

O rută recursivă, o regulă de politică care prinde peer-ul, sau o rută implicită înlocuită de un client cu tunel complet sunt cele trei cauze obișnuite. Toate trei sunt vizibile în căutarea exterioară, și niciuna nu este vizibilă într-o descărcare a tabelului principal luată după fapt.

Ce nu vă poate spune ieșirea de rutare

O căutare corectă înseamnă că nucleul ar trimite pachetul undeva sensibil. Nu înseamnă că firewall-ul îl permite, politica IPsec îl acoperă, regula NAT îl traduce, sau partea îndepărtată are o rută de întoarcere. Fiecare dintre acestea este o etapă ulterioară, iar notele strongSwan despre redirecționare descriu lanțul pe care un pachet trebuie să-l treacă la ambele capete.

De asemenea, nu ține cont de legarea la nivel de aplicație. Un proces se poate lega de o interfață, poate seta o marcă sau își poate folosi propriul rezolvator și se poate conecta cu un nume care se rezolvă diferit de ce ați testat. Când căutarea este corectă și conexiunea încă eșuează, următoarea întrebare este ce proces o face. Și anume dacă acel proces vede același tabel ca dvs.

Deci păstrați diagnosticul ordonat: numiți destinația și sursa, rulați căutarea, citiți doar tabelul și regula pe care le-a numit căutarea, apoi testați etapa următoare. Acea secvență ține o investigație de rutare în câteva minute și lasă o înregistrare pe care altcineva o poate urmări, ceea ce un tabel lipit nu face niciodată.