ಪ್ಯಾಕೆಟ್ ಕ್ಯಾಪ್ಚರ್‌ನಲ್ಲಿ ಮೊದಲ 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

ಓದಲು ಅನುಮತಿ ಇರುವಲ್ಲಿ ಅದೇ ಪ್ರಯತ್ನವನ್ನು ಸರ್ವರ್-ಬದಿಯ ಲಾಗ್‌ಗಳೊಂದಿಗೆ ಸಹಸಂಬಂಧಿಸಿ. ವಿನಂತಿ ತಲುಪಿತೇ, ಸೇವೆ ಉತ್ತರಿಸಿತೇ, ಮತ್ತು ಉತ್ತರ ಎಲ್ಲಿ ನಿಂತಿತು? ಆ ಮೂರು ಉತ್ತರಗಳು ನಿಮ್ಮನ್ನು ಮಾರ್ಗದ ಸಮಸ್ಯೆ ಅಥವಾ ನೀತಿಯ ಸಮಸ್ಯೆಗೆ ಕಳುಹಿಸುತ್ತವೆ, ಮತ್ತು ನಾಲ್ಕನೇ ಬಾರಿ ರುಜುವಾತುಗಳನ್ನು ಬದಲಿಸುವುದಕ್ಕಿಂತ ಕಡಿಮೆ ವೆಚ್ಚವಾಗುತ್ತವೆ.