Traficul trece într-adevăr prin VPN? Cum îl verificați

Două defecțiuni arată identic din pictograma din zona de notificare: traficul care intră în tunel și traficul care îl ocolește în tăcere. Clientul afișează Connected în ambele cazuri, pentru că Connected înseamnă doar că interfața tunelului există și că clientul a instalat rutele dorite. Dacă un pachet al unei aplicații a folosit acele rute este o întrebare separată, la care se răspunde în alt loc al stivei. Patru măsurători rezolvă cea mai mare parte — interogarea rutei, primul salt, o captură pe adaptorul fizic și o observație din exterior — iar vizualizarea sesiunii pe server acoperă restul.

Începeți cu ruta pe care o va lua pachetul

Tabela de rutare este decizia, așa că întrebați-o despre o singură destinație în loc să o citiți întreagă și să ghiciți. În Linux, ip route get numește interfața și adresa sursă alese de nucleu:

ip route get 203.0.113.10
ip route get 10.20.5.7

În Windows, Find-NetRoute -RemoteIPAddress 203.0.113.10 este mai util decât route print -4 din același motiv: raportează ruta care a câștigat, nu toate rutele care există. Citiți totuși tabela o dată pentru rândul ei 0.0.0.0. O pereche /1 acolo înseamnă că un client de tunel complet a rescris ruta implicită: opțiunea redirect-gateway def1 din OpenVPN instalează 0.0.0.0/1 și 128.0.0.0/1 prin tunel, ceea ce învinge 0.0.0.0/0 existentă la cea mai lungă potrivire de prefix fără a șterge ruta implicită fizică. De aceea două rute implicite pot coexista în timp ce totul intră în continuare în tunel.

Două detalii fac tabela mincinoasă. În primul rând, uitați-vă la prefixul care s-a potrivit, nu la numărul de rute implicite, pentru că metrica interfeței sau o pereche /1 decid câștigătorul. În al doilea rând, o conexiune care există deja păstrează calea cu care a fost stabilită; după ridicarea tunelului, o sesiune deschisă poate continua să folosească ruta veche până când este resetată, și de aceea reconectarea pare să repare o problemă de rutare. Un client care rulează — ps ax | grep openvpn — dovedește doar că procesul a pornit.

Urmăriți un nume intern și un nume public

Interogarea rutei arată intenția; calea arată livrarea. Urmăriți un nume care trebuie să fie intern și unul care nu trebuie, în timp ce sunteți conectat, și comparați primul salt:

traceroute intranet.corp.example
traceroute 1.1.1.1

Același prim salt pentru ambele înseamnă că numele intern nu a intrat niciodată în tunel și defecțiunea este deasupra lui, de obicei un nume care se rezolvă la o adresă publică sau o rută care nu a fost niciodată instalată. Dacă traficul intern iese prin 10.8.0.1 în timp ce cel public iese prin 192.168.1.1, tunelul divizat face exact ceea ce a fost configurat să facă. O urmă care ajunge la poarta VPN și apoi returnează doar expirări este de obicei o problemă de cale de întoarcere sau de firewall al serverului, nu o rută de redirecționare lipsă.

ICMP filtrat face această verificare mincinoasă: stelele pe ambele urme arată ca un tunel mort și de obicei sunt un firewall. Testați un port TCP unde puteți — traceroute -T -p 443 în Linux — și țineți minte că urma nu spune care resolver a răspuns: un nume se poate rezolva local și totuși să fie accesibil prin tunel.

Capturați pe adaptorul fizic, nu pe tunel

Legătura fizică este singurul loc care arată ce vede rețeaua cu adevărat. Cu tunelul ridicat, o sesiune către birou ar trebui să apară ca încărcătură criptată adresată serverului VPN, nu ca o conexiune către 10.20.5.7:

sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5

Primul filtru prinde rezolvarea numelor care iese local, care este scurgerea cea mai frecventă și cea mai tăcută — pagina se încarcă oricum, resolverul a văzut doar interogarea. Al doilea prinde trafic simplu către o adresă internă care ar trebui să existe doar în tunel. În Windows, pktmon face aceeași treabă fără driver: pktmon filter add -p 53, apoi pktmon start --capture --pkt-size 128, apoi pktmon stop și pktmon format pktmon.etl -o capture.txt. Aceste indicatori diferă puțin între versiunile de Windows, așa că verificați pktmon filter add /? înainte de a vă baza pe sintaxă.

Capturați interfața fizică pentru a găsi scurgeri; o captură pe tunel conține pachetele despre care deja credeți că sunt acolo, iar pe un server conține pachete externe ilizibile a căror sursă este poarta. Contoarele de octeți de pe orice interfață descriu pachete, nu programe; pentru a atribui trafic unui proces este nevoie de un monitor care asociază socketurile cu procesele.

Întrebați un serviciu extern, apoi întrebați din nou pentru fiecare aplicație

Singura verificare care dovedește ieșirea este un răspuns din exterior: un serviciu care returnează adresa sursă pe care a văzut-o. Rulați-l dintr-un shell, unde puteți alege interfața, și rulați-l de două ori:

sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ip

Răspunsuri diferite vă dau dovada ambelor căi și o modalitate de a testa o aplicație anume: legați-o, sau rulați-o într-un spațiu de nume de rețea cu o singură rută, și vedeți ce adresă înregistrează capătul îndepărtat. Răspunsurile identice sunt defecțiunea interesantă: fie legarea nu a avut efect, fie ceva între gazdă și capătul îndepărtat rescrie adresa sursă înainte de a ajunge. În Windows, curl --interface vrea adresa adaptorului, nu numele lui.

Un browser care raportează adresa VPN dovedește browserul. Un client de e-mail, un manager de pachete, un agent de backup sau un al doilea profil de browser pot lua fiecare o cale diferită, mai ales când o setare de proxy sau o rută de tunel divizat acoperă unul dintre ele. O schimbare de adresă nu este în sine dovada unei scurgeri: un balansator poate răspunde diferit în funcție de ieșirea văzută, așa că comparați adresa sursă înregistrată, nu pagina.

Folosiți vizualizarea serverului pentru a confirma partenerul

Serverul răspunde la o altă întrebare: dacă un partener este conectat, cât a transportat și dacă sesiunea a fost repornită. Un partener activ pe server în timp ce contoarele clientului aproape nu se mișcă înseamnă că traficul aplicației nu intră în tunel, orice ar spune tabela clientului. Un partener care mută multe date pentru un utilizator care raportează că nimic nu funcționează este o altă investigație.

Aici sunt două capcane. Un tunel mascat face fiecare flux să pară că vine de la poartă, așa că jurnalele și contabilitatea pe client se prăbușesc într-o singură adresă. Și clientul este tratat ca gazdă locală, așa că întrebarea dacă cineva copiază fișiere prin VPN primește răspuns din traficul de partajare a fișierelor pe server sau din auditul gazdei pe server — urmărirea tunelului dă capete și volum, nu nume de fișiere.

Distingeți o decizie de proiectare de o scurgere

Nu tot ce este în afara tunelului este o scurgere. Traficul de legătură locală și de difuzare rămâne local prin proiectare, o imprimantă găsită prin multicast continuă să se anunțe în LAN, iar DHCP trebuie să iasă local. O aplicație legată de o interfață anume ocolește intenționat tabela de rutare, și doar o regulă de firewall, un spațiu de nume sau o rută de politică schimbă asta.

IPv6 merită propriul rând în listă. Un tunel care transportă doar IPv4 lasă unei gazde cu stivă dublă o a doua cale utilizabilă, iar o destinație cu stivă dublă o va prefera — inclusiv DNS, dacă resolverul este accesibil prin IPv6. Dezactivați IPv6 pe adaptor sau confirmați că tunelul îl transportă înainte de a considera un rezultat IPv4 complet.

Când verificările nu concordă, nepotrivirea numește de obicei defecțiunea:

O ordine care funcționează: salvați tabela de rutare înainte și după conectare, urmăriți un nume intern și unul public, capturați DNS pe adaptorul fizic, returnați adresa de ieșire din shell pentru aplicația concretă, apoi citiți serverul pentru volum. Dacă primele patru concordă, tunelul transportă ce credeți și problema rămasă este deasupra. Dacă două dintre ele nu concordă, perechea care nu concordă este defecțiunea, nu pictograma.