Ce schimbă rutarea pe politici în traficul VPN și ce nu

Rutarea pe politici răspunde la o altă întrebare decât cea pusă de majoritatea notelor de depanare. Tabelul principal spune încotro merge o destinație; regulile de politică spun ce tabel este consultat de fapt, și pot decide asta după adresa sursă, după un marcaj de pachet, sau după interfața pe care a sosit un pachet. Când un tunel se comportă inconsecvent, setul de reguli este adesea cauza, iar tabelul de rutare adesea nu.

Regulile aleg tabelul, apoi tabelul alege ruta

Fiecare regulă poartă o prioritate, o condiție de potrivire și un tabel țintă. Nucleul parcurge regulile în ordinea priorității și se oprește la prima potrivire, apoi face o căutare obișnuită a celui mai lung prefix în acel tabel. O regulă care indică un tabel gol trece la ce selectează regula următoare, și așa o regulă scrisă cu grijă poate părea că nu face nimic.

De aceea descărcarea tabelului principal explică rar un client VPN funcțional. Clienții inserează de obicei reguli la numere de prioritate mici, mult înaintea regulii implicite a tabelului principal, așa că pachetul nu ajunge niciodată la ruta la care vă uitam. Scăderea unei metrici în tabelul principal nu schimbă nimic pentru traficul deja deviat.

O regulă poate, de asemenea, să transforme intenționat un prefix într-o gaură neagră sau să îl facă inaccesibil. Unii clienți adaugă o astfel de regulă ca întrerupător de siguranță, iar atunci căderea arată ca un tunel stricat, nu ca unul configurat.

Citiți setul de reguli ca o secvență, nu ca o listă

Tipăriți regulile cu prioritățile lor și cu tabelele la care fac referire, apoi tipăriți fiecare tabel care poartă o rută implicită sau o rută de tunel. Ordinea este partea care contează, și este partea pe care o captură de ecran o omite de obicei:

ip rule show
ip route show table all | sed -n '1,60p'
ip route get 198.51.100.20 from 10.8.0.2
ip route get 198.51.100.20 from 10.8.0.2 mark 0x1

Ultimele două comenzi sunt cele care transformă o teorie într-o observație, pentru că întreabă ce ar face nucleul pentru acea sursă și acel marcaj. Dacă răspunsul se schimbă când se schimbă marcajul, este în joc o regulă bazată pe marcaj, iar orice test care omite marcajul testează un alt pachet. Conexiunea exterioară merită o regulă proprie. Un tunel care rutează tot traficul prin el însuși trebuie să excludă adresa punctului final la care se conectează, altfel pachetele criptate sunt trimise înapoi în tunelul pe care tocmai l-au părăsit. Majoritatea clienților inserează acea excludere automat, iar un set de reguli editat manual este locul unde ea lipsește.

Marcaje și socketuri: două moduri prin care clienții împart traficul

Unii clienți marchează pachetele în firewall și adaugă o regulă care corespunde marcajului. Alții folosesc rutare la nivel de socket, punând o rută pe socket înainte ca acesta să se conecteze. Prima este vizibilă în ip rule; a doua nu, și nu va apărea într-o căutare generică.

Dacă un program de test se comportă diferit de aplicația pe care ar trebui să o reprezinte, verificați dacă aplicația pune un marcaj sau se leagă de un dispozitiv. Acea diferență nu este un mister odată ce mecanismul este numit, și explică de ce un curl dintr-un shell și o filă de browser pot lua căi diferite pe aceeași mașină. Ambele tehnici sunt rutare pe politici în sens larg: aleg o cale cu altceva decât destinația. Niciuna nu autorizează traficul, și niciuna nu înlocuiește regulile firewall sau acreditările pe care le așteaptă partenerul.

Urmăriți proprietatea înainte de a adăuga o altă regulă

Regulile sunt instalate de ceva. Un client VPN, un manager de rețea și un script scris de mână pot fiecare adăuga reguli la pornire, iar logica de reconectare poate lăsa în urmă setul anterior. Două reguli învechite dintr-un profil anterior vor continua să dirijeze traficul mult după ce profilul a fost șters.

Aflați ce proces deține regula după prioritate și formă, și verificați dacă acel proprietar rescrie setul la fiecare conexiune. Dacă o face, o regulă manuală adăugată azi dispare mâine, iar corectura aparține configurației clientului și nu unui fișier de istoric al shell-ului. Golirea întregului set de reguli pentru test este o scurtătură tentantă cu un cost previzibil: elimină și regulile de care clientul are nevoie ca să-și mențină propriul tunel funcțional. Ștergeți o regulă pe rând, sau testați pe o mașină pe care o puteți reporni.

Dovediți domeniul cu două fluxuri, nu cu unul

O corectură este verificată doar de un flux care ar trebui afectat și de un flux care nu ar trebui. Alegeți o destinație pe care politica o rutează în tunel, și una care trebuie să rămână afară, apoi comparați căutările și capturile pentru ambele:

ip route get 198.51.100.20 from 192.0.2.44
ip route get 198.51.100.21 from 192.0.2.44
tcpdump -ni any host 198.51.100.21 and port 443

Când cele două căutări returnează interfețe diferite, regula face ceva. Când returnează aceeași interfață, regula se potrivește mai larg decât s-a intenționat, și aceasta este defecțiunea care trimite în tăcere o întreagă subrețea printr-un tunel gândit pentru o singură aplicație.

Notați prioritățile regulilor și serviciul proprietar în tichet, împreună cu cele două adrese de test. Următoarea persoană are atunci o pereche reproductibilă în loc de o descriere a unui simptom, și poate spune într-un minut dacă rutarea pe politici mai este în joc.