ஒரு பாக்கெட் பிடிப்பில் முதல் 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

படிக்க அனுமதி உள்ள இடத்தில் அதே முயற்சியை சேவையகப் பக்கக் குறிப்புகளுடன் தொடர்புபடுத்துங்கள். கோரிக்கை வந்ததா, சேவை பதிலளித்ததா, பதில் எங்கு நின்றது? அந்த மூன்று பதில்களும் உங்களைப் பாதைச் சிக்கலுக்கோ கொள்கைச் சிக்கலுக்கோ அனுப்புகின்றன, நான்காவது முறை சான்றுகளை மாற்றுவதை விடக் குறைவான செலவாகும்.