De ce tcpdump arată textul simplu IPsec doar într-o singură direcție

Rulați tcpdump pe interfața exterioară a unei porți IPsec Linux și vedeți două lucruri deodată: cadre ESP de intrare și, imediat după ele, pachetele interioare decriptate. La ieșire apare doar ESP. Concluzia naturală este că răspunsurile nu sunt trimise sau că IPsec criptează o direcție și o uită pe cealaltă. Niciuna nu este adevărată.

Ce vedeți este un punct de captură. Nucleul transformă pachetele de ieșire înainte ca calea de transmisie a dispozitivului să le predea socketului de pachete, așa că socketul nu vede niciodată forma interioară la ieșire. La intrare, pachetul este capturat mai întâi ca ESP, iar copia decapsulată devine vizibilă când reintră în stivă. Același trafic, două ferestre de observare diferite.

Punctul de captură decide ce vedeți

Pe o interfață normală, un socket AF_PACKET stă aproape de stratul dispozitivului. Pachetele care părăsesc gazda trec mai întâi prin procesarea de ieșire IPsec, care transformă un segment TCP interior într-un datagram ESP sau UDP-4500, și abia apoi ajung la acel strat. Pachetele care sosesc sunt copiate în socket pe măsură ce ies din cablu, încă criptate, iar rezultatul decriptat devine vizibil mai târziu, când stiva îl livrează local sau îl transmite mai departe.

Acea ordine explică complet asimetria. Nu este o dovadă despre direcție, politică sau comportamentul aplicației, iar tratarea ei ca atare îi trimite pe oameni să urmărească un răspuns care fusese trimis corect tot timpul. Este unul dintre puținele puzzle-uri de rețea în care instrumentul, nu rețeaua, creează anomalia.

Potriviți filtrul cu stratul la care vă referiți

O expresie precum tcp port 443 selectează o conexiune TCP interioară. La ieșire, acea conexiune a devenit deja ESP în momentul în care socketul este interogat, așa că filtrul nu se potrivește cu nimic. Dacă vreți să numărați traficul protejat, filtrați după forma exterioară: protocolul 50 pentru ESP brut sau portul UDP 4500 când este folosită traversarea NAT. Ambele filtre produc un număr de pachete comparabil între cele două părți, care este de obicei motivul numărării. Niciunul nu vă spune dacă cererea interioară a primit răspuns.

Nu tratați un număr UDP 4500 ca pe un număr de pachete ESP. IKE folosește același port pentru mesajele de menținere NAT-T și pentru schimbul încapsulat, așa că numărul include trafic care nu sunt datele pe care voiați să le măsurați. Schimbul IKE inițial pe UDP 500 are nevoie de propriul filtru dacă aceasta este întrebarea. Un număr care amestecă trafic de control cu date face, de asemenea, orice estimare a lățimii de bandă greșită cu o marjă necunoscută. Numărările separate răspund la întrebări separate.

Scrieți filtrul lângă întrebarea la care răspunde. „Cât ESP a părăsit cutia” și „a părăsit cererea web cutia” sunt măsurători diferite cu filtre diferite, iar o singură captură nu le poate rezolva pe amândouă. Fără acea notă, două persoane vor compara numere care nu au numărat niciodată același lucru.

Observați înainte de transformare, nu după

Dacă trebuie să vedeți textul simplu de ieșire, mutați punctul de observare mai devreme, înainte de procesarea de ieșire IPsec. NFLOG vă oferă un cârlig Netfilter unde o regulă poate copia pachetele selectate într-un socket din spațiul utilizator, pe care tcpdump îl poate citi. Ghidul strongSwan pentru descărcarea traficului documentează această abordare exact din acest motiv.

Potrivirea politicii limitează regula la traficul care urmează să intre într-un tunel. -m policy --pol ipsec --dir out este ceea ce face regula specifică în loc să înregistreze fiecare pachet pe care cutia îl trimite. Apoi citiți grupul de jurnal cu o captură limitată: un număr mic de instantanee și o limită de dimensiune împiedică diagnosticul să devină o arhivă de trafic. O captură limitată este și mai ușor de predat unui recenzent fără a târî încărcătură irelevantă. Decideți numărul înainte de a începe, nu după ce ați văzut cât a sosit.

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

Alegeți cârligul potrivit fluxului. OUTPUT acoperă traficul generat de poarta însăși; tranzitul de la un client LAN trece prin lanțul FORWARD, iar o regulă pe OUTPUT nu îl va vedea niciodată. Adresa și portul de mai sus sunt substituenți pentru o destinație de test aprobată.

Ce demonstrează observația

NFLOG este o țintă de jurnalizare, nu o decizie de acceptare. Un pachet care apare acolo arată că a ajuns la cârlig și s-a potrivit cu regula. Nu arată că un filtru ulterior l-a permis, că dispozitivul l-a transmis sau că partenerul a primit ceva.

Un jurnal gol este la fel de ambiguu. Verificați contorul de pachete al regulii, confirmați direcția, confirmați că fluxul a corespuns într-adevăr unei politici IPsec și confirmați destinația. Doar un contor concordant pe ambii parteneri transformă o observație într-o concluzie. Apoi comparați contoarele asocierii de securitate de pe ambii parteneri pentru aceeași încercare controlată, pentru că contoarele SA sunt înregistrarea autoritară a ceea ce a fost protejat și trimis.

Încă o capcană: „text simplu” în acest context înseamnă în afara stratului de criptare IPsec. O sesiune HTTPS interioară are în continuare propriul TLS. Capturarea pachetului decapsulat nu decriptează TLS-ul aplicației, iar HTTP lizibil acolo înseamnă că aplicația nu folosea deloc HTTPS.

Curățați și comparați ambele capete

Eliminați exact regula pe care ați inserat-o, după proprietarul ei, imediat ce observarea se termină. O regulă de jurnalizare lăsată pe loc consumă CPU la fiecare pachet potrivit și creează în tăcere o problemă de păstrare a datelor. Ștergeți repetând regula cu -D în loc să goliți un lanț care nu vă aparține.

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

Dacă implementarea folosește IPsec în spațiul utilizator, o interfață XFRM sau descărcare hardware, punctele de observare se mută și această rețetă poate să nu se aplice deloc. Cu libipsec, locul documentat pentru observarea traficului interior este dispozitivul TUN. Identificați mai întâi calea, apoi alegeți punctul care răspunde la întrebare, și așteptați-vă ca cele două direcții să pară diferite doar când vă uitați la partea greșită a transformării.