ESP de ieșire fără răspuns nu înseamnă că VPN-ul este mort
ESP protejează o singură direcție pe asociație și nu confirmă nimic. Aliniază conversația interioară și SA de intrare înainte de a numi serverul neresponsiv.
Ai capturat trafic pe gazda IPsec, ai văzut pachete ESP plecând, nu ai văzut nimic întorcându-se și ai concluzionat că partea îndepărtată este defectă. Captura nu susține această concluzie. ESP protejează o singură direcție a unei conversații și nu confirmă nimic la nivelul IP, așa că lipsa ESP de retur poate însemna la fel de bine că aplicația nu avea nimic de spus, pe cât poate însemna că tunelul este mort. Citește schimbul interior și starea părții receptoare înainte de a învinui oricare capăt.
Mitul: fiecare pachet protejat primește un răspuns
ESP nu este un protocol cerere-răspuns. Criptează și autentifică tot ce selectează politica, iar receptorul validează, decriptează și livrează acel pachet interior fără a genera un pachet propriu. O interogare UDP pe care destinația o ignoră, sau un ecou ICMP pe care politica de intrare îl aruncă, produce tăcere în ambele direcții ca rezultat corect. Tratarea acelei tăceri ca o defecțiune de transport te trimite să cauți o problemă de rețea care nu a existat niciodată.
Ce dovedește de fapt o captură unidirecțională este că stiva expeditorului a criptat ceva în acel punct de observare. Nimic despre sosire și nimic despre intenția de a răspunde. Întrebarea utilă nu este „de ce nu există răspuns“ ci „ce ar fi trebuit să producă conversația interioară“.
Două SA, două SPI, o conversație
Asociațiile de securitate IPsec sunt unidirecționale, așa că un schimb protejat normal rulează o asociație de intrare și una de ieșire cu identificatori separați și stare independentă. Căutarea traficului de retur după SPI-ul pachetului de ieșire este prin urmare o eroare de categorie, deoarece orice răspuns călătorește sub propria SA de ieșire a partenerului, cu propriul SPI. În schimb, potrivește perechea după selectorii de trafic și adresele partenerului.
Reînnoirea cheii complică imaginea pentru câteva secunde, deoarece starea veche și cea de înlocuire se pot suprapune. Dacă simptomul a început în jurul unei reînnoiri a cheii, colectează identificatorii asociațiilor și marcajele de timp împreună, nu doar numele conexiunii.
Ce trebuie să facă receptorul înainte ca ceva să răspundă
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
Fiecare rând eșuează independent și fiecare defecțiune are alt proprietar, motiv pentru care o singură captură nu le poate distinge. Contorul de intrare este singura dovadă directă a sosirii, deoarece un pachet care nu trece autentificarea sau verificarea repetării este aruncat fără niciun răspuns. Un partener al cărui contor de intrare nu s-a mișcat nu îți oferă, așadar, nicio informație despre politica sa.
Livrarea este un pas separat de decriptare. Starea poate fi validă și pachetul totuși aruncat ulterior de o politică de intrare sau de o rută care nu include destinația interioară, așa că verifică dacă gazda țintă a văzut text simplu, în loc să presupui că un contor curat înseamnă că pachetul a mers unde ai vrut.
ESP nativ nu este UDP
ESP nativ este protocolul IP 50, care nu este nici TCP, nici UDP și nu are niciun port. O regulă de firewall care permite IKE pe UDP 500 nu spune deci nimic despre calea de date, iar un filtru scris în jurul porturilor poate lăsa un tunel să negocieze și apoi să arunce tot ce este purtat înăuntru. Testează calea de date separat, în modul pe care l-ai observat efectiv.
În spatele NAT forma se schimbă: încărcătura protejată călătorește în interiorul UDP, de obicei pe portul 4500, cum definește RFC 3948. Înregistrează modul activ înainte de a scrie orice regulă, deoarece un dispozitiv de pe cale poate trata ESP nativ și ESP încapsulat în UDP complet diferit, iar unele cutii intermediare permit unul aruncându-l pe celălalt.
Citește contoarele care aparțin acestui incident
Pe o gazdă strongSwan, swanctl --list-sas raportează contoare de pachete și octeți pe asociație în ambele direcții, ceea ce este suficient pentru a separa „nu a sosit niciodată“ de „a sosit și nu a fost răspuns“. Pe Linux, /proc/net/xfrm_stat numără eșecuri agregate precum stare lipsă, politică lipsă și erori de protocol. Aceste totaluri se acumulează de la pornire și aparțin unui singur spațiu de nume de rețea, așa că un număr mare nu este o atribuire.
Ia două citiri în jurul ferestrei incidentului în spațiul de nume corect și compară deltele, altfel vei pune erorile de săptămâna trecută pe tichetul de astăzi după-amiază. Pune spațiul de nume și ambele marcaje de timp în tichet, astfel încât următorul cititor să poată reproduce comparația în loc să se bazeze pe un total.
Numește etapa, nu suspectul
O concluzie utilă spune unde s-a oprit pachetul: niciodată primit, primit și aruncat, livrat dar fără răspuns, sau răspuns și pierdut pe drumul de întoarcere. Fiecare dintre acestea indică un alt proprietar și o altă comandă următoare. „Niciun răspuns de la serverul VPN“ colapsează patru defecțiuni distincte într-o propoziție pe care captura nu a justificat-o niciodată.
Păstrează capturile înguste și ține starea brută a nucleului în afara tichetelor, deoarece poate purta material de cheie care nu ar trebui să părăsească gazda. Deltele contoarelor și marcajele de timp sunt părțile care merită predate următoarei persoane.