Pot rutele DHCP să trimită traficul în jurul tunelului VPN?

Criptarea începe la o graniță, iar acea graniță este o decizie de rutare pe care punctul final o ia înainte ca vreun pachet să fie încapsulat. O rețea care nu vede niciodată cheile tale poate totuși să îi dea mașinii tale o rută care îi place mai mult decât cea a tunelului. Aici se confundă două eșecuri: citirea unui pachet aflat deja în tunel și direcționarea unui pachet care nu a fost pus niciodată acolo.

Distincția contează pentru că al doilea eșec este mai ieftin de aranjat și mult mai ușor de ratat. Apare ca o cerere care a ieșit prin interfața greșită în timp ce clientul raporta în continuare o conexiune sănătoasă.

Două moduri în care o rețea te poate afecta

Un pachet care ajunge în tunel are conținutul ascuns de fiecare hop pe care îl traversează, iar protecția rezistă chiar și când calea te surprinde. Un pachet care nu ajunge niciodată în tunel este o cerere obișnuită din adresa ta, trimisă acolo unde indica tabela de rutare. Primul eșec cere un cifru spart sau un partener compromis, în timp ce al doilea cere doar un mesaj de configurare în care mașina ta a ales să aibă încredere. Această asimetrie este motivul pentru care jumătatea de rutare merită o verificare separată.

Echipamentele de pe cale nu au nevoie de cheile tale ca să influențeze al doilea caz. Au nevoie doar ca punctul tău final să accepte o rută, un resolver sau o regulă de politică ce produce una.

expected:  app -> tunnel device -> encapsulation -> internet
observed:  app -> wlan0        -> plaintext     -> internet

De unde poate veni o rută înainte ca tunelul să existe

DHCP distribuie mai mult decât un contract de închiriere a adresei. Opțiunea de rute statice fără clasă poate transporta prefixe de destinație și următoarele hopuri, iar RFC 3442 discută consecințele de securitate ale unei adrese de router greșite: trafic direcționat greșit, o negare de serviciu sau un observator aflat pe cale. Un client care acceptă acele rute înainte ca tunelul să fie activ poate ajunge cu o cale preferată care nu are nimic de-a face cu furnizorul tău.

Nimic din toate acestea nu face injectarea de rute universală. Clientul trebuie să accepte opțiunea, prefixul trebuie să acopere traficul care te interesează, următorul hop ales trebuie să fie accesibil, iar politica de aplicare trebuie să permită pachetului să iasă pe acea cale. Elimină oricare dintre acestea și același răspuns devine inofensiv. Tot de aceea două mașini din aceeași rețea se pot comporta diferit, fiindcă nu rulează același client, aceeași politică sau măcar aceeași familie de adrese.

IPv6 merită o trecere separată, pentru că anunțurile routerului transportă o rută implicită prin alt cod decât opțiunea DHCPv4. Un test care inspectează doar tabela v4 nu acoperă asta.

Verifică calea pe care kernelul o selectează efectiv

Interogările de rută pot primi răspuns, așa că întreabă-le în loc să deduci dintr-un bec de stare. Comenzile de mai jos arată ruta și sursa alese pentru o destinație, plus regulile care pot suprascrie tabela principală. Rulează-le cât ești conectat și din nou după o reconectare, pentru că reînnoirea contractului poate schimba răspunsul.

ip route get 203.0.113.10
ip route show table all | grep -E '^(default|203\.0\.113)'
ip rule show
resolvectl query example.com

Citește rezultatul pentru două lucruri: interfața numită în rută și adresa sursă aleasă. O rută de tunel numește dispozitivul tunelului, o rută scursă numește dispozitivul fizic, iar diferența se vede fără să decriptezi nimic. Dacă răspunsul se schimbă între rulări, păstrează ambele rezultate și compară regulile care le-au produs.

Nu te opri la ruta implicită. O excepție de aplicație, un prefix de tunel divizat sau o a doua regulă de politică pot duce o destinație anume în jurul tunelului în timp ce implicitul încă indică înăuntru.

Decide unde trebuie să stea aplicarea

Trei condiții decid dacă aplicarea pe partea clientului este suficientă sau ai nevoie de ceva din afara ei. Dacă clientul instalează și apără rute pentru fiecare familie de adrese pe care o folosești, un tunel care deține ruta implicită este de obicei suficient. Dacă mașina trebuie să atingă resurse locale în timp ce tot restul rămâne în tunel, acele excepții trebuie enumerate și asumate, nu lăsate pe seama a ce a anunțat rețeaua de acces. Și dacă platforma poate lega traficul de o interfață pe aplicație, acea legare este o garanție mai puternică decât o rută pe care orice o poate suprascrie.

Orice ai alege, scrie decizia acolo unde locuiește configurația. O regulă care există pentru că cineva a tastat-o în timpul unui incident nu va supraviețui următoarei reporniri, așa că ține excepțiile locale și de pornire înguste și notează de ce există fiecare.

Rulează din nou comenzile de interogare după fiecare actualizare a clientului și fiecare schimbare de rețea, și compară cu ultimul rezultat înregistrat. Tabela de rutare este granița de aplicare, așa că trateaz-o ca atare.