Unde urmărești traficul unui client OpenVPN pe gateway

Vrei să afli ce destinații atinge un client conectat, așa că deschizi un shell pe serverul VPN și tastezi ss. Nu apare nimic util, iar concluzia că tunelul este stricat vine puțin prea ușor. Un gateway OpenVPN cu rutare transmite pachetele clientului; nu le termină conexiunile TCP și nu deține socketuri pentru ele. Dovada trăiește în altă parte, iar unde anume depinde de modul în care traficul este tratat după ce părăsește tunelul.

Stabilește la ce configurație te uiți

Două forme obișnuite produc dovezi complet diferite. Un gateway care rutează decapsulează, transmite și poate aplica NAT de sursă, așa că conexiunea clientului continuă să existe de la un capăt la altul fără socket local.

Un proxy termină traficul: acceptă conexiunea, apoi deschide propria conexiune în amonte. În această configurație există două conexiuni pentru o cerere, iar asocierea dintre ele există doar în înregistrările proxy-ului. A ști pe care dintre ele ai implementat-o decide dacă trebuie să citești starea fluxurilor din kernel sau jurnalele aplicației.

Cea mai mare parte a confuziei vine din presupuneri. Confirmă forma înainte de a alege instrumentul. Citește mai întâi configurația serverului pentru o directivă de proxy, pentru că prezența ei schimbă fiecare pas ulterior. Fără ea, calea pachetelor este rutare, iar starea fluxurilor din kernel este dovada ta.

Leagă mai întâi adresa de o sesiune

Începe de la starea sesiunilor serverului și identifică adresa internă curentă a clientului. Adresele din grup sunt reciclate, așa că o adresă singură este o închiriere, nu o persoană.

Notează împreună ora și identitatea autentificată și observă dacă o întreagă rețea locală se ascunde în spatele acelui client. Dacă capătul îndepărtat rutează o subrețea, adresele interne pe care le vezi pot fi gazde originale sau traduse.

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

Perechea aceea răspunde la două întrebări deodată: ce prefix deservește interfața tunelului și ce sesiune a fost activă în intervalul care te interesează. Fă asta înainte de a interpreta orice intrare de flux, pentru că un tuplu convingător atașat sesiunii greșite este mai rău decât nicio dovadă.

Citește tabelul de fluxuri pe un gateway care rutează

Odată stabilite adresa și intervalul, o listare doar-citire a conexiunilor urmărite arată ce transmite gateway-ul pentru ea. Filtrează după sursa originală ca să nu citești tot tabelul.

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

Fiecare intrare conține două tupluri, original și răspuns, care sunt cele două direcții ale unui singur flux, nu două aplicații. Pe o cale cu NAT de sursă tuplul original păstrează adresa tunelului, iar partea de răspuns arată adresa tradusă a gateway-ului, și exact asta face ca ieșirea să pară greșită la prima vedere.

Tratează listarea ca stare vie și nu ca istoric. Fluxurile scurte pot fi expirat deja, traficul neurmărit nu apare niciodată, iar alt spațiu de nume de rețea arată alt tabel. Referința conntrack documentează filtrele și ieșirea în două direcții.

O captură limitată pentru a confirma citirea

Dacă interfața tunelului este vizibilă acolo unde te uiți, o singură captură limitată lămurește dacă pachetele pe care le-ai identificat sunt cele de pe fir. Ține filtrul îngust și limita de pachete mică.

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

Compară marcajele de timp, protocolul și porturile cu intrarea de flux și cu cererea pe care ai făcut-o ca test. O captură luată după NAT arată doar adresa publică a gateway-ului, în timp ce partea tunelului poate arăta încă adresa clientului, iar acea diferență este informație, nu o inconsistență.

Dacă interfața nu vede nimic, verifică calea datelor înainte de a concluziona că clientul este inactiv: traficul între clienți și unele căi de descărcare nu trec niciodată prin punctul pe care îl urmărești.

Jurnalele proxy și limitele a ceea ce ai văzut

Când un proxy stă pe cale, socketurile sale în amonte sunt vizibile în tabelul de socketuri, dar nu se mapează unu-la-unu pe clienții VPN, mai ales cu gruparea în pool sau multiplexarea. Folosește jurnalul de tranzacții configurat al proxy-ului pentru a corela identitatea clientului, destinația, marcajul de timp și orice identificator de cerere pe care îl înregistrează.

Verifică configurația de jurnalizare a versiunii implementate în loc să presupui că fiecare cerere este înregistrată implicit.

În final, fii precis cu privire la domeniu. O adresă de destinație și un port sunt metadate, nu un URL și nu conținutul paginii, pentru că sesiunea HTTPS interioară își păstrează propria protecție indiferent de tunel. Raportează ce ai observat, din ce punct de observare și la ce oră.