Hoe om die eerste IKEv2-uitruiling in 'n pakketopname te lees
Pas die IKE_SA_INIT-versoek en -antwoord op SPI en boodskap-ID, onderskei IKE van ingekapselde ESP op 4500, en sien wat 'n stil spoor kan bewys.
Opnames midde in die sessie is die gewone rede waarom 'n IKEv2-spoor soos geraas lyk, want die eweknieë is reeds besig om sleutels te vernuwe of versleutelde vragte uit te ruil wanneer die opname begin. Begin eerder met 'n vars verbindingspoging, sodat die eerste boodskap in die lêer die een is wat die onderhandeling open. Die leesorde hieronder aanvaar dit, en dit merk die punt waar 'n pakket ophou om iets oor die ander kant te bewys. Om daardie stap oor te slaan, is hoe 'n werkende tonnel as 'n geblokkeerde poort gediagnoseer word.
Bevestig dat jy na die openingsuitruiling kyk
'n IKEv2-onderhandeling begin met IKE_SA_INIT, uitruilingtipe 34, boodskap-ID 0. Die inisieerder kies 'n nie-nul SPI, en die responder-SPI is nul in daardie eerste versoek en nie-nul in die antwoord. Daardie drie feite skei 'n vars poging van 'n sleutelvernuwing of van 'n IKE_AUTH-boodskap wat toevallig heel bo in 'n opname sit.
Kopvelde is leesbaar, en so ook die voorstel-, sleuteluitruiling- en nonce-vragte. Leesbaar is nie geauthentiseer nie: geen van die eweknieë het op hierdie punt identiteit bewys nie, en die Diffie-Hellman-privaatwaarde verskyn nooit op die draad nie.
Druk die velde as 'n tabel uit eerder as om deur 'n dekodeerpaneel te rol, want hertransmissies en SPIs wat nie pas nie, word in kolomme duidelik.
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
Lees die uitset in pare. 'n Versoek met boodskap-ID 0 gevolg deur 'n antwoord met dieselfde ID en 'n nie-nul responder-SPI is een uitruiling, selfs wanneer dit drie keer verskyn omdat die versoek hertransmitteer is. Drie identiese versoeke is nie drie aanmeldings nie, en om hulle so te behandel, is hoe mense aflei dat 'n kliënt loop terwyl dit net geduldig is. Sorteer volgens boodskap-ID, dan volgens tydstempel, en die hele gesprek val in 'n kort lys pogings saam.
Lees 'n verwerping voordat jy 'n sukses lees
'n Antwoord is nie outomaties vordering nie. Die responder kan met 'n cookie-kennisgewing antwoord en verwag dat die inisieerder weer probeer, of met INVALID_KE_PAYLOAD wat 'n groep noem wat hy eerder sou aanvaar. Albei kom as goed gevormde IKE-boodskappe aan, en albei lyk soos 'n afgehandelde uitruiling vir 'n filter wat net pakkies tel.
Maak die kennisgewingvrag oop en lees die tipe voor enigiets anders. 'n Cookie-uitdaging beteken die responder verdedig hom teen vervalste bronadresse, en die kliënt moet weer stuur met die cookie aangeheg. 'n Ongeldige groep beteken die twee voorstelle stem nie ooreen nie, wat geen hoeveelheid herprobeer sal verander voordat een kant se konfigurasie skuif nie.
Net IKE_AUTH, die tweede uitruiling, dra die versleutelde identiteit en die authentiseringsvragte. 'n Voltooide IKE_SA_INIT sê dus dat die eweknieë oor algoritmes en afgeleide sleutels saamstem, en glad niks oor of die geloofsbriewe aanvaar sal word nie. Verwag ook twee boodskappe daar, en verwag dat albei ondeursigtig is sonder die sessiesleutels.
Poort 4500 is nie een protokol nie
UDP 500 dra gewoonlik die openingsuitruiling. Sodra NAT-opsporing geloop het, skuif IKE na 4500 en sit 'n viergreep nul nie-ESP-merker voor elke boodskap. Ingekapselde ESP op dieselfde poort begin eerder met 'n nie-nul ESP-SPI, en 'n NAT-lewendeboodskap van een greep is 'n derde vorm wat verskyn wanneer niks anders gebeur nie.
'n Filter wat net die poort pas, meng al drie, en daarom besluit "daar is verkeer op 4500" so min. Verdeel die aansig volgens protokol voordat jy enigiets oor die eweknie aflei.
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
Stilte beskryf die waarnemingspunt
Versoeke sonder antwoorde bewys presies een ding: by daardie opnamepunt het geen antwoord verskyn nie. Filtering, 'n roete wat die antwoord elders heen stuur, 'n onbereikbare responder, of 'n responder wat nie van die voorstel hou nie, lewer almal dieselfde leë resultaat, en 'n generiese UDP-toets sal hulle nie skei nie.
'n ICMP-onbereikbaar is bewyse van 'n ander soort. Lees die aangehaalde pakket daarin en identifiseer watter toestel dit uitgestuur het, want 'n roeteerder se administratiewe verwerping is nie 'n geauthentiseerde fout van die eweknie nie.
tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code
Korreleer dieselfde poging met bedienerkant-logboeke waar jy dit mag lees. Het die versoek aangekom, het die diens geantwoord, en waar het die antwoord gestop? Daardie drie antwoorde stuur jou na 'n padprobleem of na 'n beleidsprobleem, en hulle kos minder as om geloofsbriewe 'n vierde keer te roteer.