IPsec ESP: ce transportă și cum dovedești că circulă

ESP transportă traficul într-o VPN IPsec, iar runbook-ul său începe cu o regulă: citiți asocierea de securitate înainte de a schimba o politică. Cea mai mare parte a comportamentului neexplicat al ESP se reduce la un selector care nu se potrivea, la un mod presupus în loc de citit, sau la un contor pe care nimeni nu l-a verificat în timp ce se trimitea un singur flux. Cei trei pași de mai jos stabilesc ce transportă ce, dovedesc că un flux îl folosește și lasă o revenire care nu depinde de memorie. Fiecare pas produce o observație care merită notată.

Cunoașteți câmpurile înainte de a le citi

ESP pune un antet în fața datelor protejate și un trailer în spate. Antetul poartă un indice al parametrilor de securitate care identifică ce asociere trebuie să folosească receptorul, un număr de secvență pentru detectarea repetărilor și, în trailer, umplutură care ține sarcina utilă aliniată pentru cifru. Câmpul de antet următor din trailer spune care este conținutul protejat, și așa receptorul știe ce a decapsulat.

Modul schimbă ce se află în interiorul acelei protecții. În modul tunel materialul protejat este un pachet IP interior complet, iar un antet exterior nou îl transportă între capete. În modul transport protecția înfășoară sarcina utilă a stratului superior al unui pachet existent, deci nu există un al doilea antet IP de deschis. Care mod este folosit este un fapt de configurare, nu o chestiune de interpretare. Citiți-l din intrarea de stare în loc să îl deduceți dintr-o diagramă.

Niciunul dintre moduri nu ascunde adresarea exterioară care trebuie să livreze pachetul. Aceasta este o proprietate a designului, nu o lipsă, și de aceea un observator intermediar poate vedea în continuare care două adrese vorbesc, chiar și atunci când sarcina utilă este opacă.

Primul pas: citiți starea, apoi politica

Intrările de stare țin cheile și contoarele; intrările de politică țin selectorii care decid ce poate să le folosească. În Linux ambele sunt vizibile fără capturarea pachetelor, iar citirea lor în această ordine ține cele două întrebări separate.

ip xfrm state
ip xfrm policy

În ieșirea de stare, verificați sursa și destinația asocierii, modul și dacă încapsularea arată porturi UDP. Acele porturi înseamnă că se folosește traversarea NAT, ceea ce schimbă ce trebuie să permită un firewall intermediar, dar nu ce selectori sau chei se aplică la capete.

Apoi citiți selectorii din politică. Un selector care numește un prefix mai îngust decât traficul pe care îl testați este cel mai frecvent motiv pentru care un tunel funcțional pare să ignore un flux, iar un selector pentru protocolul greșit produce aceeași tăcere.

Instrumentele producătorilor tipăresc aceleași informații într-o formă mai comodă. ipsec statusall în strongSwan listează asocierile copil, selectorii lor și contoarele lor de octeți, ceea ce este adesea mai rapid decât citirea ieșirii xfrm brute când știți deja la ce copil să vă uitați.

Al doilea pas: dovediți că un flux mișcă contoarele

Contoarele au sens doar dacă știți ce ar fi trebuit să le miște, așa că alegeți o sursă și o destinație pe care selectorul le acoperă cu siguranță și trimiteți o cerere inofensivă. Apoi recitiți aceeași intrare și comparați.

ip -s xfrm state
tcpdump -ni any esp

Două citiri spun povești diferite. Pachetele care cresc pe partea de ieșire dar niciodată pe cea de intrare indică o problemă de transmitere sau de cale de întoarcere, nu de cheie, pentru că pachetul a fost încapsulat și a plecat. Dacă niciun contor nu se mișcă, traficul nu s-a potrivit niciodată cu politica, iar selectorul este locul unde trebuie să priviți.

Captura din același pas confirmă încapsularea pe fir, inclusiv dacă pachetele exterioare sunt ESP sau ESP încapsulat în UDP. Vă arată și adresele care au transportat efectiv fluxul, iar acestea diferă uneori de cele din configurația pe care o citeați.

Al treilea pas: schimbați un singur lucru și păstrați o revenire

Notați sursa, destinația, modul, selectorii și contoarele asocierii înainte de a edita ceva. Dacă o schimbare înrăutățește lucrurile, acea notă este cea care vă permite să restaurați starea anterioară în loc să reconstruiți o configurație funcțională dintr-o presupunere. Nota durează un minut și economisește o oră mai târziu. Este și singurul artefact care supraviețuiește persoanei care a făcut schimbarea.

Schimbați un selector sau un parametru, reîncărcați-l și repetați al doilea pas pe același flux. Ștergerea unei asocieri dărâmă fiecare flux care o folosește, așa că o editare țintită și o reîncărcare a copilului sunt aproape întotdeauna mai bune decât golirea stării pentru a vedea ce se întâmplă.

Revenirea pentru o editare de selector înseamnă restaurarea politicii anterioare și reîncărcarea ei, cu rezerva că partenerul poate avea nevoie de o schimbare corespunzătoare dacă selectorul este negociat, nu local. Notați această dependență cât este proaspătă, pentru că o pereche pe jumătate restaurată este mai greu de analizat decât oricare dintre cele două stări finale.

În final, păstrați domeniul onest. O asociere ESP care circulă dovedește că cele două porți protejează și livrează segmentul și nu spune nimic despre dacă aplicația de deasupra își autentifică utilizatorii sau criptează ce stochează. Acestea sunt controale separate cu dovezi separate, iar runbook-ul este gata doar când următoarea persoană îl poate repeta din note.