Hvernig á að lesa fyrstu IKEv2-skiptin í pakkaskráningu
Paraðu IKE_SA_INIT-beiðnina og svarið við hana eftir SPI og skilaboðaauðkenni, greindu IKE frá innvafðri ESP á 4500 og sjáðu hvað hljótt slóð getur sannað.
Skráningar sem teknar eru um miðja lotu eru venjulega ástæðan fyrir því að IKEv2-slóð virðist hávaði, því aðilarnir eru þegar að endurnýja lykla eða skiptast á dulrituðum farmi þegar upptakan hefst. Byrjaðu frekar á nýrri tilraun til tengingar þannig að fyrsta skilaboðin í skránni séu þau sem opna samningaviðræðurnar. Lestraröðin hér að neðan gerir ráð fyrir því og merkir þann punkt þar sem pakki hættir að sanna hvað sem er um fjarlæga endann. Að sleppa því skrefi er hvernig vinnandi göng eru greind sem lokað port.
Staðfestu að þú sért að skoða opnunarskiptin
IKEv2-samningaviðræður byrja með IKE_SA_INIT, skiptatýpu 34, skilaboðaauðkenni 0. Frumkvæðisaðilinn velur SPI sem er ekki núll, og SPI svaraðilans er núll í þeirri fyrstu beiðni og ekki núll í svarinu. Þessar þrjár staðreyndir aðgreina nýja tilraun frá lyklendurnýjun eða frá IKE_AUTH-skilaboðum sem lenda fyrir tilviljun efst í skráningu.
Hausreitirnir eru læsilegir, og það sama gildir um tillögu-, lyklaskipta- og nonce-farminn. Læsilegt er ekki auðkennt: hvorugur aðilinn hefur sannað auðkenni á þessum punkti, og einkagildi Diffie-Hellmans birtist aldrei á línunni.
Prentaðu reitina sem töflu í stað þess að skruna um afkóðunarglugga, því endursendingar og SPI sem passa ekki verða augljós í dálkum.
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
Lestu úttakið í pörum. Beiðni með skilaboðaauðkenni 0 sem fylgt er eftir af svari með sama auðkenni og SPI svaraðilans sem er ekki núll er ein skipti, jafnvel þótt hún birtist þrisvar sinnum vegna þess að beiðnin var endursend. Þrjár eins beiðnir eru ekki þrjár innskráningar, og að meðhöndla þær þannig er hvernig fólk kemst að þeirri niðurstöðu að biðlari fari í lykkju þegar hann er bara þolinmóður. Raðaðu eftir skilaboðaauðkenni og síðan tímastimplum, og allt samtalið minnkar í stuttan lista yfir tilraunir.
Lestu höfnun áður en þú lest árangur
Svar er ekki sjálfkrafa framfarir. Svaraðilinn getur svarað með cookie-tilkynningu og búist við að frumkvæðisaðilinn reyni aftur, eða með INVALID_KE_PAYLOAD sem nefnir hóp sem hann myndi frekar samþykkja. Bæði berast sem vel mótuð IKE-skilaboð, og bæði líta út eins og lokið skipti fyrir síu sem telur bara pakka.
Opnaðu tilkynningarfarminn og lestu týpuna áður en nokkuð annað er gert. Cookie-áskorun þýðir að svaraðilinn ver sig gegn fölsuðum upprunavistföngum, og biðlarinn verður að senda aftur með cookie viðhengi. Ógildur hópur þýðir að tillögurnar tvær stangast á, sem engin endurtekning breytir fyrr en stilling annars aðilans hreyfist.
Aðeins IKE_AUTH, önnur skiptin, flytur dulritaða auðkennið og auðkenningarfarminn. Lokið IKE_SA_INIT segir þér því að aðilarnir séu sammála um reiknirit og afleidda lykla, og ekkert sem helst um hvort skírteinin verði samþykkt. Búðu líka við tveimur skilaboðum þar, og búðu við að bæði séu ógagnsæ án lotulyklanna.
Port 4500 er ekki eitt samskiptareglur
UDP 500 flytur venjulega opnunarskiptin. Þegar NAT-greining hefur keyrt færist IKE á 4500 og setur fjögurra bæta núllmerki sem er ekki ESP fyrir framan hvert skilaboð. Innvafð ESP á sama porti byrjar aftur á móti á ESP-SPI sem er ekki núll, og einnar bætis NAT-keepalive er þriðja formið sem birtist þegar ekkert annað gerist.
Sía sem passar bara við portið blandar öllum þremur, og þess vegna skerir "það er umferð á 4500" svo litlu úr. Skiptu sýninni eftir samskiptareglum áður en þú ályktar nokkuð um fjarlæga endann.
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
Þögn lýsir athugunarpunktinum
Beiðnir án svara staðfesta nákvæmlega eitt: á þeim skráningarpunkti birtist ekkert svar. Sía, leið sem sendir svarið annað, óaðgengilegur svaraðili eða svaraðili sem líkar ekki tillagan framleiða öll sama tóma niðurstöðu, og almenn UDP-prófun aðgreinir þau ekki.
ICMP-óaðgengileiki er sönnun af annarri gerð. Lestu tilvitnaða pakkann inni í honum og greindu hvaða tæki sendi hann, því stjórnunarleg höfnun frá beini er ekki auðkennt villa frá fjarlæga endanum.
tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code
Tengdu sömu tilraun við annála á þjónshlið þar sem þér er heimilt að lesa þá. Kom beiðnin, svaraði þjónustan og hvar stöðvaðist svarið? Þessi þrjú svör senda þig í vandamál með leið eða vandamál með stefnu, og þau kosta minna en að skipta um skírteini í fjórða sinn.