Cum se citește primul schimb IKEv2 într-o captură de pachete

Capturile făcute la mijlocul unei sesiuni sunt motivul obișnuit pentru care o urmă IKEv2 arată ca zgomot, fiindcă părțile deja reînnoiesc chei sau schimbă încărcături cifrate când începe înregistrarea. Începe în schimb cu o nouă încercare de conectare, astfel încât primul mesaj din fișier să fie cel care deschide negocierea. Ordinea de citire de mai jos presupune asta și marchează punctul în care un pachet nu mai dovedește nimic despre capătul îndepărtat. Trecerea peste acel pas este modul în care un tunel funcțional ajunge diagnosticat ca port blocat.

Confirmă că privești schimbul de deschidere

O negociere IKEv2 începe cu IKE_SA_INIT, tip de schimb 34, ID de mesaj 0. Inițiatorul alege un SPI diferit de zero, iar SPI-ul respondenților este zero în acea primă cerere și diferit de zero în răspuns. Aceste trei fapte separă o încercare nouă de o reînnoire de chei sau de un mesaj IKE_AUTH care se află din întâmplare în capul unei capturi.

Câmpurile antetului sunt lizibile, la fel ca încărcăturile de propunere, schimb de chei și nonce. Lizibil nu înseamnă autentificat: nicio parte nu a dovedit identitatea în acest punct, iar valoarea privată Diffie-Hellman nu apare niciodată pe fir.

Tipărește câmpurile ca tabel în loc să derulezi un panou de decodare, fiindcă retransmisiile și SPI-urile care nu se potrivesc devin evidente pe coloane.

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

Citește ieșirea în perechi. O cerere cu ID de mesaj 0 urmată de un răspuns care poartă același ID și un SPI de respondență diferit de zero este un singur schimb, chiar și când apare de trei ori fiindcă cererea a fost retransmisă. Trei cereri identice nu sunt trei autentificări, iar tratarea lor ca atare este felul în care se concluzionează că un client se învârte în buclă când de fapt e doar răbdător. Sortează după ID-ul mesajului, apoi după marcajul temporal, și toată conversația se reduce la o listă scurtă de încercări.

Citește un refuz înainte de a citi un succes

Un răspuns nu este automat progres. Respondența poate răspunde cu o notificare cookie și să aștepte ca inițiatorul să încerce din nou, sau cu INVALID_KE_PAYLOAD numind un grup pe care l-ar accepta în schimb. Ambele sosesc ca mesaje IKE bine formate, și ambele arată ca un schimb încheiat pentru un filtru care doar numără pachete.

Deschide încărcătura de notificare și citește tipul înainte de orice altceva. O provocare cookie înseamnă că respondența se apără împotriva adreselor de sursă falsificate, iar clientul trebuie să retrimită cu cookie-ul atașat. Un grup invalid înseamnă că cele două propuneri nu sunt de acord, ceea ce nicio reîncercare nu va schimba până când configurația unei părți nu se mișcă.

Doar IKE_AUTH, al doilea schimb, transportă identitatea cifrată și încărcăturile de autentificare. Un IKE_SA_INIT finalizat îți spune deci că părțile sunt de acord asupra algoritmilor și cheilor derivate, și absolut nimic despre dacă acreditările vor fi acceptate. Așteaptă-te și acolo la două mesaje, și așteaptă-te ca ambele să fie opace fără cheile de sesiune.

Portul 4500 nu este un singur protocol

UDP 500 transportă de obicei schimbul de deschidere. După ce detecția NAT a rulat, IKE trece pe 4500 și pune în fața fiecărui mesaj un marcator nul de patru octeți care nu este ESP. ESP încapsulat pe același port începe în schimb cu un SPI ESP diferit de zero, iar un keepalive NAT de un singur octet este o a treia formă care apare când nu se întâmplă nimic altceva.

Un filtru care se potrivește doar pe port le amestecă pe toate trei, de aceea "există trafic pe 4500" lămurește atât de puțin. Desparte vizualizarea după protocol înainte de a concluziona ceva despre capătul îndepărtat.

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

Tăcerea descrie punctul de observare

Cererile fără răspuns stabilesc exact un lucru: în acel punct de captură nu a apărut niciun răspuns. Filtrarea, o rută care trimite răspunsul în altă parte, o respondență inaccesibilă sau o respondență căreia nu-i place propunerea produc toate același rezultat gol, iar o sondă UDP generică nu le va separa.

Un ICMP inaccesabil este o dovadă de alt tip. Citește pachetul citat din interiorul lui și identifică ce dispozitiv l-a emis, fiindcă refuzul administrativ al unui router nu este o eroare autentificată de la capătul îndepărtat.

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

Corelează aceeași încercare cu jurnalele de pe partea serverului acolo unde îți este permis să le citești. A ajuns cererea, a răspuns serviciul și unde s-a oprit răspunsul? Acele trei răspunsuri te trimit spre o problemă de rută sau spre o problemă de politică, și costă mai puțin decât o a patra rotire a acreditărilor.