Kā lasīt jaunu IKE_SA_INIT apmaiņu ierakstā

Sāciet ar ierakstu, kas sākas pirms mēģinājuma pirmā paketa, citādi jūs lasīsiet sarunas vidu. Jau notiekoša saruna rāda šifrētas apmaiņas un atslēgu atjauninājumus, un neviens no tiem neizskatās kā sākums. Sākums ir tā daļa, ko var atšifrēt bez atslēgām, tāpēc tas tik labi atbild uz sasniedzamības jautājumiem. Četras pārbaudes pēc kārtas ved jūs no svaiga ieraksta līdz aizstāvamam apgalvojumam par to, kura puse pārtrauca runāt.

Pirmkārt, pārliecinieties, ka ieraksts sākas no sākuma

Ieraksts, kas sākts pēc tuneļa pacelšanas, saturēs iekapsulēto datu plūsmu un periodiskus keepalive, un abi ir vai nu šifrēti, vai gandrīz tukši. Restartējiet klientu un ierakstiet pašu mēģinājumu, vai arī apzināti izraisiet jaunu savienojumu, kamēr ieraksts darbojas. Ja nevarat radīt svaigu mēģinājumu, pierakstiet to savās piezīmēs, jo neviena atšifrēšana neatgūst sākumu, ko nekad neesat ierakstījis.

Ierobežojiet ierakstu ar diviem galapunktiem un UDP 500 un 4500, lai fails paliktu pietiekami mazs lasīšanai. Noslogotā saimniekā nefiltrēts ieraksts apraka sarunu zem nesaistītas plūsmas.

tcpdump -i any -n -s 0 -w fresh-ike.pcap 'udp port 500 or udp port 4500'

Saglabājiet failu, kad mēģinājums ir interesants, jo tas pats ieraksts atbild uz abiem nākamajiem jautājumiem: kas bija apmaiņa un vai kaut kas atgriezās. Atzīmējiet to ar sākuma laiku un to galapunktu pāri, pēc kura filtrējāt. Ieraksts bez šiem diviem faktiem pēc nedēļas ir bezjēdzīgs, kad adreses ir mainījušās un neviens neatceras, kurš mēģinājums tika ierakstīts.

Otrkārt, lasiet galveni pirms lietderīgās kravas

IKE galvene nes drošības parametru indeksus, apmaiņas tipu un ziņojuma ID, un jaunā sarunā šīs vērtības ir atšķirīgas. Iniciators izdomā SPI, kas nav nulle, sākotnējais pieprasījums nes atbildētāja nulles SPI, jo atbilde vēl nav redzēta, apmaiņas tips ir IKE_SA_INIT, un ziņojuma ID ir nulle. Viss pārējais pieder vēlākam tās pašas sarunas posmam vai pavisam citam mēģinājumam.

Šīs pirmās apmaiņas priekšlikuma, atslēgu apmaiņas un nonce kravas ir lasāmas atklātā veidā. Lasāmība nav autentifikācija, un šajā brīdī neviena puse nav pierādījusi savu identitāti.

Privātā Diffie-Hellman vērtība nekad nešķērso vadu, tāpēc ieraksts neļauj atvasināt sesijas atslēgas. Autentifikācija notiek nākamajā apmaiņā, aizsargāta ar to, par ko vienojās pirmā. Ja kāds jautā, vai puse ir īsta, šī apmaiņa nevar atbildēt uz šo jautājumu. Tā var tikai parādīt, ka abas puses vienojās par priekšlikumu un radīja kopīgu noslēpumu, kura failā nav.

Treškārt, saskaņojiet pieprasījumu ar tā atbildi

Saskaņojiet pēc SPI pāra, apmaiņas tipa un ziņojuma ID, pēc tam pārbaudiet atbildes karodziņu. Atkārtota nosūtīšana atkārto oriģināla ziņojuma ID un nav otrs pieteikšanās mēģinājums. Pakešu skaitīšana apmaiņu vietā ir ceļš, kā vesela saruna pārvēršas fantoma cilpā.

Atbilde var būt arī atteikums: sīkdatņu pieprasījums, paziņojums par nepieņemamu grupu vai kļūda par priekšlikumu. Tās ir likumīgas atbildes, un tās nozīmē, ka ceļš darbojas, bet politika ne. Atšifrējiet paziņojumu, nevis uzskatiet katru atbildi par panākumu. Kad paziņojums nosauc grupu vai priekšlikumu, labojums ir konfigurācijas pusē, nevis ugunsmūrī.

Virziens arī ir svarīgs. Pieprasījums bez atbildes un atbilde, kas nekad nesasniedz klientu, ir dažādi defekti, un tikai otrais izskatās kā klienta puses taimauts.

Ceturtkārt, atdaliet IKE no visa cita 4500 portā

4500 ports nes trīs lietas, kas kopsavilkumā izskatās vienādi: IKE aiz četru baitu nulles non-ESP marķiera, iekapsulēts ESP, kura marķiera pozīcijā ir SPI, kas nav nulle, un īsi keepalive. Tieši marķieris atdala IKE no iekapsulētā ESP, tāpēc izlasiet tos baitus pirms plūsmas nosaukšanas par IKE. Ieraksta etiķete, kas lasa 4500, ir porta numurs, nevis protokols.

Iekapsulēts ESP ir šifrēta krava, ko nevarat interpretēt bez atslēgām, un tā klātbūtne var būt strādājoša tuneļa pazīme, nevis defekts.

Vērojiet abus portus vienam un tam pašam mēģinājumam, jo IKE var pāriet uz 4500 pēc NAT noteikšanas, lai gan atvērās uz 500. Tikai uz 500 filtrētas pēdas izskatās kluss tieši tad, kad saruna izdevās un pārvietojās. Paplašiniet filtru un izlasiet to pašu laika logu vēlreiz, pirms izdarāt kādu secinājumu no neesamības.

Ko nozīmē klusums vienā novērojumu punktā

Atbildes neesamība klientā pierāda tikai to, ko šis punkts novēroja. Filtrēšana, maršrutēšana, nepareiza attālā adrese, apstājusies pakalpojums un protokola neatbilstība visi dod vienu un to pašu tukšo pēdu.

Atbilstošs ICMP unreachable pievieno pierādījumu, bet izlasiet tajā citēto pakešu un pierakstiet to nosūtījušās ierīces adresi.

Maršrutētāja atteikums ir cits notikums nekā puses atgriezta autentificēta kļūda, un tikai otrais pierāda, ka pakalpojums ir dzīvs. Korelējiet to pašu mēģinājumu ar servera žurnāliem vai apstiprinātu novērojumu, lai uzzinātu, vai pieprasījums ieradās un vai atbilde aizgāja. Turiet ierakstus ierobežotus un privātus, jo lasāmie rokasspiediena lauki nepadara pārējo failu nekaitīgu. Rezultāts, kas ir tā vērts, ir viens saskaņots pieprasījums un atbilde, vai viena dokumentēta plaisa ar nosauktu novērojumu punktu.