Traficul pe eth0 nu înseamnă că tunelul VPN are scurgeri
Adresele publice de pe adaptorul fizic sunt de obicei ambalajul tunelului însuși. Comparați interfețele, apoi întrebați nucleul ce dispozitiv alege.
Să vezi adrese publice pe eth0 în timp ce tunelul este activ pare dovada că ceva a scăpat. De obicei este invers: pachetele tunelului însuși trebuie să traverseze acel adaptor pentru a ajunge la server, iar ele arată ca fluxuri UDP sau TCP obișnuite. Pachetul interior apare doar pe dispozitivul tunelului. A distinge cele două este o chestiune de a citi ambalajul, nu de a avea încredere într-un număr de octeți.
Fiecare pachet al tunelului traversează totuși firul
Un tunel este o interfață, nu un fir. Clientul ia un pachet interior, îl înfășoară și trimite rezultatul la adresa și portul serverului din profil. Pe adaptorul fizic vedeți ambalajul; pe dispozitivul tunelului vedeți ceea ce a fost înfășurat.
În modul UDP fluxul exterior este o singură pereche de adresă și port în fiecare direcție, de aceea un tunel sănătos pare aproape plictisitor pe eth0. Exact acea pereche unică este primul lucru de căutat.
Capturați o singură interfață o dată
Capturați o singură interfață o dată când intenționați să comparați numărări. Pseudointerfața any colectează toate dispozitivele deodată, așa că un pachet redirecționat apare la intrare și la ieșire, iar unul generat local apare de două ori în două forme diferite. Numărări egale de pachete cu numărări diferite de octeți sunt normale, pentru că ambalajul este mai mare decât ceea ce transportă. ARP, DHCP și anunțurile routerului IPv6 aparțin legăturii locale și nu spun nimic despre aplicația dumneavoastră.
sudo tcpdump -i eth0 -n host 203.0.113.10 and udp port 1194Înlocuiți adresa și portul cu valorile profilului însuși. Dacă acel flux este constant, tunelul transportă ceva.
Întrebați nucleul ce dispozitiv alege
Întrebați nucleul ce dispozitiv ar alege, apoi confirmați pe fir. Căutarea rutei este decizia, iar captura este dovada că decizia a fost urmată. Ele răspund la întrebări diferite și aveți nevoie de ambele.
ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111Un rezultat despărțit este descoperirea obișnuită: IPv4 merge în tunel, iar IPv6 merge la adaptorul fizic pentru că profilul a împins doar rute IPv4. Aceasta este o scurgere reală și este invizibilă într-o captură doar cu IPv4. Filtrați IPv6 și urmăriți adresele care nu sunt serverul și nu sunt link-local.
Rulați ambele căutări înainte și după conectare, ca să vedeți ce a schimbat clientul de fapt. Diferența dintre cele două rulări este efectul real al clientului.
Când captura este într-adevăr o scurgere
Uneori captura spune adevărul. O rută mai îngustă care trimite un prefix pe lângă tunel, o subrețea care i s-a spus clientului să o excludă, sau o acceptare din firewall care rulează înaintea politicii tunelului pot toate scoate trafic pe fir în clar. O regulă care corespunde unui grup de procese poate fi și o excepție deliberată. Citiți interfața și domeniul destinației înainte de a o numi defect.
Reparați ruta sau excluderea, nu firewallul. Apoi capturați din nou dintr-o conexiune nouă și verificați IPv4 și IPv6 separat, pentru că repararea unuia nu spune nimic despre celălalt. manualul tcpdump acoperă selectorii de interfață și de direcție folosiți mai sus.