పాకెట్ క్యాప్చర్‌లో మొదటి IKEv2 పరిమార్పును ఎలా చదవాలి

సెషన్ మధ్యలో తీసుకున్న క్యాప్చర్లే IKEv2 జాడ శబ్దంగా కనిపించడానికి సాధారణ కారణం, ఎందుకంటే రికార్డింగ్ ప్రారంభమయ్యే సమయంలో రెండు వైపులా ఇప్పటికే కీలను పునరుద్ధరిస్తున్నాయి లేదా గుప్తీకరించిన పేలోడ్లను పరిమార్పు చేస్తున్నాయి. బదులుగా కొత్త కనెక్షన్ ప్రయత్నంతో ప్రారంభించండి, తద్వారా ఫైల్‌లో మొదటి సందేశమే చర్చను తెరిచే సందేశం అవుతుంది. క్రింది పఠన క్రమం అదే ఊహిస్తుంది మరియు పాకెట్ దూర చివర గురించి ఏమీ నిరూపించలేని బిందువును గుర్తిస్తుంది. ఆ దశను దాటవేయడమే పని చేస్తున్న టన్నెల్ నిరోధించిన పోర్ట్‌గా నిర్ధారణ కావడానికి కారణం.

మీరు ప్రారంభ పరిమార్పును చూస్తున్నారని నిర్ధారించుకోండి

IKEv2 చర్చ IKE_SA_INIT తో ప్రారంభమవుతుంది, పరిమార్పు రకం 34, సందేశ ఐడీ 0. ప్రారంభకుడు సున్నా కాని SPI ఎంచుకుంటాడు, ప్రతిస్పందించేవారి SPI ఆ మొదటి అభ్యర్థనలో సున్నా మరియు ప్రతిస్పందనలో సున్నా కాదు. ఆ మూడు వాస్తవాలు కొత్త ప్రయత్నాన్ని కీ పునరుద్ధరణ లేదా క్యాప్చర్ పైభాగంలో యాదృచ్ఛికంగా ఉన్న IKE_AUTH సందేశం నుండి వేరు చేస్తాయి.

హెడర్ ఫీల్డ్‌లు చదవగలిగేవి, ప్రతిపాదన, కీ పరిమార్పు మరియు nonce పేలోడ్లు కూడా అలాగే. చదవగలగడం అంటే ధృవీకరించబడిందని కాదు: ఈ సమయంలో ఏ వైపూ గుర్తింపును నిరూపించలేదు, Diffie-Hellman యొక్క ప్రైవేట్ విలువ ఎప్పుడూ తీగపై కనిపించదు.

డీకోడ్ ప్యానెల్ స్క్రోల్ చేయడం బదులు ఫీల్డ్‌లను పట్టికగా ముద్రించండి, ఎందుకంటే పునఃప్రసారాలు మరియు సరిపోలని SPI లు నిలువు వరుసల్లో స్పష్టమవుతాయి.

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

అవుట్‌పుట్‌ను జతలుగా చదవండి. సందేశ ఐడీ 0 ఉన్న అభ్యర్థన తర్వాత అదే ఐడీ మరియు సున్నా కాని ప్రతిస్పందించేవారి SPI కలిగిన ప్రతిస్పందన ఒకే పరిమార్పు, అభ్యర్థన మళ్లీ పంపబడినందున అది మూడుసార్లు కనిపించినా. ఒకేలాంటి మూడు అభ్యర్థనలు మూడు లాగిన్‌లు కావు, అలా పరిగణించడమే క్లయింట్ లూప్‌లో తిరుగుతోంది అనే నిర్ణయానికి దారి తీస్తుంది, వాస్తవానికి అది కేవలం ఓపికగా ఉంది. సందేశ ఐడీ ప్రకారం, ఆపై సమయ ముద్ర ప్రకారం క్రమబద్ధీకరించండి, మొత్తం సంభాషణ చిన్న ప్రయత్నాల జాబితాగా కుదిస్తుంది.

విజయాన్ని చదవడానికి ముందు తిరస్కరణను చదవండి

ప్రతిస్పందన స్వయంచాలక ప్రగతి కాదు. ప్రతిస్పందించేవారు cookie నోటిఫికేషన్‌తో ప్రతిస్పందించి ప్రారంభకుడు మళ్లీ ప్రయత్నిస్తాడని ఆశించవచ్చు, లేదా బదులుగా అంగీకరించే సమూహాన్ని పేర్కొనే INVALID_KE_PAYLOAD తో. రెండూ సరిగ్గా రూపొందించిన IKE సందేశాలుగా వస్తాయి, పాకెట్లను మాత్రమే లెక్కించే ఫిల్టర్‌కు రెండూ పూర్తయిన పరిమార్పుగానే కనిపిస్తాయి.

నోటిఫికేషన్ పేలోడ్ తెరిచి అన్నింటికంటే ముందు రకాన్ని చదవండి. cookie సవాలు అంటే ప్రతిస్పందించేవారు నకిలీ మూల చిరునామాల నుండి తమను కాపాడుకుంటున్నారు, క్లయింట్ cookie జోడించి మళ్లీ పంపాలి. చెల్లని సమూహం అంటే రెండు ప్రతిపాదనలు ఏకీభవించలేదు, ఒక వైపు సంరచన మారే వరకు ఎన్ని మళ్లీ ప్రయత్నించినా అది మారదు.

గుప్తీకరించిన గుర్తింపు మరియు ధృవీకరణ పేలోడ్లను IKE_AUTH మాత్రమే, అంటే రెండవ పరిమార్పు, మోసుకెళ్తుంది. అందువల్ల పూర్తయిన IKE_SA_INIT రెండు వైపులా అల్గారిథమ్‌లు మరియు ఉత్పన్న కీలపై ఏకీభవిస్తున్నాయని మాత్రమే చెబుతుంది, ఆధారాలు అంగీకరించబడతాయా అనే దాని గురించి ఏమీ చెప్పదు. అక్కడ కూడా రెండు సందేశాలను ఆశించండి, సెషన్ కీలు లేకుండా రెండూ అపారదర్శకంగా ఉంటాయని ఆశించండి.

4500 పోర్ట్ ఒకే ప్రోటోకాల్ కాదు

ప్రారంభ పరిమార్పును సాధారణంగా UDP 500 మోసుకెళ్తుంది. NAT గుర్తింపు నడిచిన తర్వాత IKE 4500 కి మారి ప్రతి సందేశానికి ముందు నాలుగు బైట్ల సున్నా ESP కాని గుర్తును పెడుతుంది. అదే పోర్ట్‌పై ఎన్‌క్యాప్సులేట్ చేసిన ESP బదులుగా సున్నా కాని ESP SPI తో ప్రారంభమవుతుంది, ఒక బైట్ NAT keepalive మరేదీ జరగనప్పుడు కనిపించే మూడవ రూపం.

పోర్ట్‌తో మాత్రమే సరిపోలే ఫిల్టర్ మూడింటినీ కలుపుతుంది, అందుకే "4500 పై ట్రాఫిక్ ఉంది" అనేది చాలా తక్కువ నిర్ణయిస్తుంది. దూర చివర గురించి ఏదైనా నిర్ణయించే ముందు వీక్షణను ప్రోటోకాల్ ప్రకారం విభజించండి.

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

నిశ్శబ్దం పర్యవేక్షణ బిందువును వివరిస్తుంది

ప్రతిస్పందన లేని అభ్యర్థనలు సరిగ్గా ఒక విషయాన్ని స్థాపిస్తాయి: ఆ క్యాప్చర్ బిందువు వద్ద ఎలాంటి ప్రతిస్పందన కనిపించలేదు. ఫిల్టరింగ్, ప్రతిస్పందనను వేరే చోటికి పంపే మార్గం, చేరుకోలేని ప్రతిస్పందించేవారు, లేదా ప్రతిపాదన ఇష్టపడని ప్రతిస్పందించేవారు అందరూ ఒకే ఖాళీ ఫలితాన్ని ఇస్తారు, సాధారణ UDP పరీక్ష వాటిని వేరు చేయదు.

ICMP చేరుకోలేకపోవడం మరో రకమైన సాక్ష్యం. దానిలోని ఉద్ధృత పాకెట్‌ను చదివి ఏ పరికరం దాన్ని విడుదల చేసిందో గుర్తించండి, ఎందుకంటే రౌటర్ పరిపాలనా తిరస్కరణ దూర చివర నుండి వచ్చిన ధృవీకరించిన లోపం కాదు.

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

చదవడానికి అనుమతి ఉన్న చోట అదే ప్రయత్నాన్ని సర్వర్ వైపు లాగ్‌లతో సహసంబంధం చేయండి. అభ్యర్థన చేరిందా, సేవ ప్రతిస్పందించిందా, ప్రతిస్పందన ఎక్కడ ఆగింది? ఆ మూడు ప్రతిస్పందనలు మిమ్మల్ని మార్గ సమస్య లేదా విధాన సమస్య వైపు పంపుతాయి, నాల్గవసారి ఆధారాలను మార్చడం కంటే తక్కువ ఖర్చు.