IKEv2 UDP 500 ಮತ್ತು 4500 ಬಳಸುತ್ತದೆ: ಯಾವ ಪೋರ್ಟ್ ಡೇಟಾವನ್ನು ಸಾಗಿಸುತ್ತದೆ?

ಫೈರ್ವಾಲ್ನಲ್ಲಿ UDP 500 ತೆರೆದರೆ ಸುರಂಗ ಮಾತುಕತೆ ನಡೆಸುತ್ತದೆ, ನಂತರ ಸಂಪರ್ಕ ಟ್ರಾಫಿಕ್ ಸಾಗಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಪೋರ್ಟ್ ಪಟ್ಟಿ ಅಪೂರ್ಣವಾಗಿತ್ತು, ತಪ್ಪಲ್ಲ. IKEv2 ಒಂದು ಸಾಕೆಟ್ನಲ್ಲಿ ಪ್ರಾರಂಭವಾಗಿ ಅನೇಕ ನೈಜ ನಿಯೋಜನೆಗಳಲ್ಲಿ ಇನ್ನೊಂದರಲ್ಲಿ ಮುಂದುವರಿಯುತ್ತದೆ, ಆದರೆ ಪೇಲೋಡ್ ಪೋರ್ಟ್ ಆಗಿರದೇ ಇರಬಹುದು. ಹಂತಗಳನ್ನು ಕ್ರಮವಾಗಿ ಓದುವುದು ಯಾವ ನಿಯಮ ಕಾಣೆಯಾಗಿದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಎರಡು ಪೋರ್ಟ್, ಎರಡು ಕೆಲಸ

IKEv2 UDP 500 ಮೇಲೆ ಕೀಲಿ ವಿನಿಮಯದಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಅಲ್ಲಿ ಎರಡೂ ಕಡೆಗಳು ದೃಢೀಕರಿಸಿಕೊಂಡು ಸುರಂಗಕ್ಕೆ ಭದ್ರತಾ ಸಂಘಟನೆಯನ್ನು ಸ್ಥಾಪಿಸುತ್ತವೆ. ನಂತರದ ಡೇಟಾ ಮಾರ್ಗ ಬೇರೆ ವಿಷಯ: ಅದು ಪೋರ್ಟ್ ಅಲ್ಲದ IP ಪ್ರೋಟೋಕಾಲ್ ಸಂಖ್ಯೆಯಾದ ಸ್ಥಳೀಯ ESP ಆಗಿರಬಹುದು, ಅಥವಾ 4500 ಮೇಲೆ UDP ಒಳಗೆ ಸುತ್ತಿದ ಟ್ರಾಫಿಕ್ ಆಗಿರಬಹುದು. ಫೈರ್ವಾಲ್ ಪರಿಶೀಲನೆಯಲ್ಲಿ ಇವೆರಡನ್ನು ಬೇರೆ ಬೇರೆಯಾಗಿ ಇಡುವುದೇ ಮಾತುಕತೆ ನಡೆಸುವ ಸುರಂಗ ಮತ್ತು ಕೆಲಸ ಮಾಡುವ ಸುರಂಗದ ನಡುವಿನ ವ್ಯತ್ಯಾಸ. ಒಂದು ಸಾಕೆಟ್ ನಿಯಂತ್ರಣವನ್ನು ಸಾಗಿಸುತ್ತದೆ, ಇನ್ನೊಂದು ಪೇಲೋಡ್.

ಆದ್ದರಿಂದ ಕೇವಲ 500 ಅನ್ನು ಅನುಮತಿಸುವ ನಿಯಮ ಇಡೀ ಪ್ರೋಟೋಕಾಲ್ ಕುಟುಂಬದಲ್ಲಿ ಅತ್ಯಂತ ಗೊಂದಲದ ಲಕ್ಷಣವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ: ಮಾತುಕತೆ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ ಮತ್ತು ಉಪಯುಕ್ತವಾದುದು ಏನೂ ಮುಂದುವರಿಯುವುದಿಲ್ಲ. ಸ್ಥಿತಿ ಪೀರ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ, ಲಾಗ್ ಸ್ಥಾಪಿತ IKE SA ಅನ್ನು ತೋರಿಸುತ್ತದೆ, ಆದರೂ ಅಪ್ಲಿಕೇಶನ್ ಸಮಯ ಮೀರುತ್ತದೆ. ಕಾಣೆಯಾದ ಅನುಮತಿ ಈಗಷ್ಟೇ ಯಶಸ್ವಿಯಾದ ಹರಿವಿಗಿಂತ ಬೇರೆ ಹರಿವಿಗೆ ಸೇರಿದೆ.

4500 ಏಕೆ ಇದೆ

ಅನೇಕ NAT ಸಾಧನಗಳು TCP ಅಥವಾ UDP ಹೊರತುಪಡಿಸಿ ಬೇರೆ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ರವಾನಿಸಲಾರವು, ಕೆಲವು ವಿಳಾಸಗಳನ್ನು ESP ಯ ಸಮಗ್ರತಾ ಪರಿಶೀಲನೆಯನ್ನು ಮುರಿಯುವ ರೀತಿಯಲ್ಲಿ ಬರೆಯುತ್ತವೆ. ESP ಅನ್ನು UDP ಒಳಗೆ ಸುತ್ತುವುದು ಎರಡೂ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ಹೆಚ್ಚುವರಿ ಹೆಡರ್ ಮತ್ತು ಅನುಮತಿಸಬೇಕಾದ ಎರಡನೇ ಪೋರ್ಟ್ ವೆಚ್ಚದಲ್ಲಿ. ಆ ಸುತ್ತುವಿಕೆಯೇ ಎರಡನೇ ಪೋರ್ಟ್ ಇರುವುದಕ್ಕೆ ಕಾರಣ.

NAT ಪತ್ತೆಯಾದ ನಂತರ IKE ಸ್ವತಃ 4500 ಗೆ ಹೋಗುತ್ತದೆ, ಎಲ್ಲಾ ಟ್ರಾಫಿಕ್ ಅನುವಾದಕದ ಮೂಲಕ ಒಂದೇ ಮಾರ್ಗವನ್ನು ಹಂಚಿಕೊಳ್ಳಲು. ESP ಅಲ್ಲದ ನಾಲ್ಕು ಬೈಟ್ ಗುರುತು ಆ ಸಾಕೆಟ್ನಲ್ಲಿ ನಿಯಂತ್ರಣ ಸಂದೇಶಗಳನ್ನು ಡೇಟಾದಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ. ಈ ಬದಲಾವಣೆ ಪ್ರೋಟೋಕಾಲ್ ನಿರ್ಧಾರ, ನಿರ್ವಾಹಕರ ಆಯ್ಕೆಯಲ್ಲ.

ಮೂಲ ಪೋರ್ಟ್ ಎಲ್ಲಿ ಬದಲಾಗುತ್ತದೆ

ಅನುವಾದಕ ಕ್ಲೈಂಟ್ನ ಮೂಲ ಪೋರ್ಟ್ ಅನ್ನು ಮರುಬರೆಯಬಹುದು, ಹೀಗಾಗಿ ಸರ್ವರ್ನಲ್ಲಿ ಕಾಣುವ ಟ್ಯೂಪಲ್ ಕ್ಲೈಂಟ್ನ ಟ್ಯೂಪಲ್ಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ನಿಯಮವನ್ನು ನಿರ್ಲಕ್ಷಿಸಲಾಗುತ್ತಿದೆ ಎಂದು ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ಪ್ರತಿ NAT ಹಾಪ್ನ ಎರಡೂ ಬದಿಗಳನ್ನು ನೋಡಿ. ಕೇವಲ ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಸಮಸ್ಯೆ ಹುಡುಕುವುದು ಸರಿಯಾಗಿ ಕಾಣುವ ಆದರೆ ವಿಫಲವಾಗುವ ನಿಯಮವನ್ನು ನೀಡಬಹುದು.

MOBIKE ಸಮರ್ಥ ಅನುಷ್ಠಾನಗಳು NAT ಪತ್ತೆಯಾಗದೆಯೂ 4500 ಗೆ ಹೋಗಬಹುದು, ಕೆಲವು ನಿಯೋಜನೆಗಳು ಆ ಮಾರ್ಗವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಒತ್ತಾಯಿಸುತ್ತವೆ. ಆದ್ದರಿಂದ 4500 ನೋಡುವುದು ನಿರ್ಧಾರದ ಸಾಕ್ಷ್ಯ, ಮನೆಯ ರೌಟರ್ನ ಸಾಕ್ಷ್ಯವಲ್ಲ.

ಪ್ರತಿ ಗಡಿಯಲ್ಲಿ ಎರಡೂ ಹರಿವುಗಳನ್ನು ಪರಿಶೀಲಿಸಿ

ಮೂರು ಗಡಿಗಳನ್ನು ದಾಟಿ: ಕ್ಲೈಂಟ್ ನೆಟ್ವರ್ಕ್, ಯಾವುದೇ ಮಧ್ಯಂತರ ಫೈರ್ವಾಲ್ ಮತ್ತು ಸರ್ವರ್. ಪ್ರತಿಯೊಂದಕ್ಕೂ ನಿಯೋಜನೆ ದಾಖಲಿಸುವ ಹರಿವುಗಳು ಬೇಕು, ಬೇರೆ ಪ್ರಕರಣದ ಬಗ್ಗೆ ಲೇಖನದ ಹರಿವುಗಳಲ್ಲ.

sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state

ಫೈರ್ವಾಲ್ ಪಟ್ಟಿಯಲ್ಲಿ ESP ಸಾಲು ಪ್ರೋಟೋಕಾಲ್ ಹೊಂದಾಣಿಕೆ, ಆದ್ದರಿಂದ ಪೋರ್ಟ್ ನಿಯಮ ಅದನ್ನು ಎಂದಿಗೂ ಆವರಿಸುವುದಿಲ್ಲ. ನಿರ್ವಾಹಕರು ಕಸ್ಟಮ್ ಪೋರ್ಟ್ ಬಳಸಿದರೆ, ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ದಾಖಲಾದ ಸಂರಚನೆಯನ್ನು ಅನುಸರಿಸಿ, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ ಪರಿಚಿತ ಸಂಖ್ಯೆಯನ್ನು ಆಯ್ಕೆಮಾಡಿ ಸರ್ವರ್ನಲ್ಲಿ ಶ್ರೋತೆಯನ್ನು ರಚಿಸಲಾರದು.

ಮಾತುಕತೆ ಎಲ್ಲಿ ನಿಂತಿತು ಮತ್ತು ಮಗು ಭದ್ರತಾ ಸಂಘಟನೆ ಸ್ಥಾಪನೆಯಾಯಿತೇ ಎಂದು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಈ ಜೋಡಿ ತಡೆಗಟ್ಟಿದ ಮಾರ್ಗವನ್ನು ದೃಢೀಕರಣ ಅಥವಾ ನೀತಿ ದೋಷದಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ. ನಂತರ ಸರ್ವರ್ ಪರಿಶೀಲನೆ ಸಕ್ರಿಯವಾಗಿ ಪರೀಕ್ಷೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ, ಏಕೆಂದರೆ ತಲುಪುವಿಕೆ ದೃಢೀಕರಣವಲ್ಲ. ಆ ಕೊನೆಯ ಹಂತ ಅನುಮತಿಸಿದ ಪೋರ್ಟ್ ಅನ್ನು ವಿಶ್ವಾಸಾರ್ಹ ಪೀರ್ನಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ.