strongSwan ESP-in-UDP: ಪತ್ತೆಹಚ್ಚಲು NAT ಇಲ್ಲದಿದ್ದಾಗ

NAT ಪತ್ತೆ ಸರನಾಮೆಗಳ ಅನುವಾದವನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತದೆ, ಫೈರ್‌ವಾಲ್ ನೀತಿಯನ್ನಲ್ಲ. NAT ಇಲ್ಲದ ಸೈಟ್ ಸಂಪರ್ಕಕ್ಕೆ ಇನ್ನೂ ಸ್ಪಷ್ಟ ESP-in-UDP ಆಯ್ಕೆ ಬೇಕಾಗಬಹುದು.

NAT ಪತ್ತೆ ಒಂದು ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ದಾರಿಯಲ್ಲಿ ಸರನಾಮೆಗಳು ಅಥವಾ ಪೋರ್ಟ್‌ಗಳು ಬದಲಾದವೇ? ಫೈರ್‌ವಾಲ್ IP ಪ್ರೋಟೋಕಾಲ್ 50 ಅನ್ನು ಅನುಮತಿಸುತ್ತದೆಯೇ ಎಂಬುದಕ್ಕೆ ಅದು ಉತ್ತರಿಸುವುದಿಲ್ಲ. ಯಾವುದೇ ಅನುವಾದವಿಲ್ಲದ ಸೈಟ್ ಗೇಟ್‌ವೇಗಳು native ESP ಅನ್ನು ಬಿಡುವ ನೀತಿಯ ಹಿಂದೆ ಇನ್ನೂ ಇರಬಹುದು, ಮತ್ತು ಆ ಅಗತ್ಯವನ್ನು ಕಂಡುಕೊಳ್ಳುವ ಬದಲು ಸಂರಚಿಸಬೇಕು. ಕಾರ್ಯವಿಧಾನ ESP-in-UDP, ಮತ್ತು ಇದು ನಿರ್ಣಯವೇ ಹೊರತು ತಾನಾಗಿ ಬರುವ ಪರ್ಯಾಯವಲ್ಲ.

ಪತ್ತೆ ಸರನಾಮೆಗಳ ಮೇಲಿನ ಅಂಕಗಣಿತ, ಫೈರ್‌ವಾಲ್ ಪ್ರೋಬ್ ಅಲ್ಲ

IKEv2 NAT ಪತ್ತೆ ಪೇಲೋಡ್‌ಗಳನ್ನು ಒಯ್ಯುತ್ತದೆ, ಅವು ಮೂಲ ಮತ್ತು ಗಮ್ಯ ಸರನಾಮೆಗಳ ಹಾಗೂ ಪೋರ್ಟ್‌ಗಳ ಹ್ಯಾಶ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ. ಪ್ರತಿ ಬದಿಯೂ ಸ್ವೀಕರಿಸಿದ್ದನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಕಾಣುವುದರೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ, ಮತ್ತು ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ ಯಾವುದೋ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಅನುವಾದಿಸಿದೆ ಎಂದು ಅದಕ್ಕೆ ತಿಳಿಯುತ್ತದೆ. ಆ ವಿನಿಮಯದಲ್ಲಿ ಮಧ್ಯದ ರೌಟರ್ ಪ್ರೋಟೋಕಾಲ್ 50 ಅನ್ನು ರವಾನಿಸುತ್ತದೆಯೇ ಎಂದು ಪರೀಕ್ಷಿಸುವ ಯಾವುದೂ ಇಲ್ಲ.

ಪ್ರಾಯೋಗಿಕ ಪರಿಣಾಮವನ್ನು ನೇರವಾಗಿ ಹೇಳುವುದು ಯೋಗ್ಯ. native ESP ಜೊತೆ ಕೆಲಸ ಮಾಡಿದ ಸುರಂಗವು ಹೊಸ ನಿರ್ಬಂಧಕ ಫೈರ್‌ವಾಲ್ ಅನ್ನು ತಾನೇ ಕಂಡುಕೊಳ್ಳುವುದಿಲ್ಲ, ಮತ್ತು IKE ಯಶಸ್ವಿಯಾಗುತ್ತಲೇ ಇರುವಾಗ ಅದರ ಮುಂದಿನ ಪ್ರಯತ್ನ ಡೇಟಾ ಹಂತದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. ನೀವು ಸ್ಥಾಪಿತ IKE ಭದ್ರತಾ ಸಂಘಗಳನ್ನು ನೋಡುತ್ತೀರಿ ಮತ್ತು ಯಾವುದೇ ಸಂರಕ್ಷಿತ ಸಂಚಾರವಿಲ್ಲ, ಇದು ತಂತಿಯಲ್ಲಿ ಸೆರೆಹಿಡಿಯುವವರೆಗೆ ರೌಟಿಂಗ್ ದೋಷದಂತೆ ಕಾಣುತ್ತದೆ.

ಆದ್ದರಿಂದ ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್ ನೀವು ಸಂರಚಿಸುವ ಸಂಪರ್ಕದ ಗುಣಲಕ್ಷಣ, ಜಾಲದ ವರ್ತನೆಯಿಂದ ಕಡೆಗಳು ಮಾತುಕತೆ ನಡೆಸುವ ಫಲಿತಾಂಶವಲ್ಲ.

encap ವಿನಿಮಯವನ್ನು ಹೇಗೆ ಬದಲಿಸುತ್ತದೆ

ಆಧುನಿಕ strongSwan ನಿಯೋಜನೆಯಲ್ಲಿ, ಅದು swanctl.conf ಮೂಲಕ ನಿರ್ವಹಿಸಲ್ಪಡುತ್ತದೆ, ಸಂಪರ್ಕದಲ್ಲಿ encap = yes ಸೆಟ್ಟಿಂಗ್ NAT ಪತ್ತೆ ವಿನಿಮಯದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ, ಇದರಿಂದ ಎರಡೂ ಕಡೆಗಳು ESP ಗೆ UDP ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಬಳಸುತ್ತವೆ. ಸಂರಕ್ಷಿತ ಪ್ಯಾಕೆಟ್‌ಗಳು ನಂತರ UDP ಒಳಗೆ, ಸಾಮಾನ್ಯವಾಗಿ ಪೋರ್ಟ್ 4500 ನಲ್ಲಿ ಸಂಚರಿಸುತ್ತವೆ, ಮತ್ತು ಎರಡೂ ತುದಿಗಳು ಈ ವ್ಯವಸ್ಥೆಗೆ ಒಪ್ಪಬೇಕು.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

ಆ ತುಣುಕು ನಿಜವಾದ ಸಂಪರ್ಕ ವ್ಯಾಖ್ಯಾನದ ಒಳಗೆ ಸೇರುತ್ತದೆ ಮತ್ತು ಪೂರ್ಣ ಸೈಟ್ ಪ್ರೊಫೈಲ್ ಅಲ್ಲ. ನೀವು ಈಗಾಗಲೇ ನಡೆಸುತ್ತಿರುವ ಪೀರ್ ಸರನಾಮೆಗಳು, ದೃಢೀಕರಣ ಮತ್ತು child ಸಂಚಾರ ಆಯ್ಕೆಗಾರರನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ; ಸೇರಿಸಿದ ಏಕೈಕ ಕೀ ಸಂರಕ್ಷಿತ ಡೇಟಾವನ್ನು ಹೇಗೆ ಸುತ್ತುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ, ಅದು ಏನನ್ನು ರಕ್ಷಿಸುತ್ತದೆ ಎಂಬುದನ್ನಲ್ಲ.

strongSwan ನ NAT-traversal ಮಾರ್ಗದರ್ಶಿ ಈ ವರ್ತನೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ, MOBIKE ಬಳಸಿದಾಗ ಪೋರ್ಟ್ ಫ್ಲೋಟಿಂಗ್‌ನೊಂದಿಗಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಯೂ ಸೇರಿದಂತೆ.

ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಸೇರಿದ ಸೆಟ್ಟಿಂಗ್ ಬಳಸಿ

strongSwan ಗೆ ಎರಡು ಸಂರಚನಾ ಬ್ಯಾಕೆಂಡ್‌ಗಳಿವೆ, ಮತ್ತು ಕೀ ಅವುಗಳ ನಡುವೆ ಭಿನ್ನವಾಗಿದೆ. swanctl.conf ಸಂಪರ್ಕ encap ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಹಳೆಯ ipsec.conf ಸಂಪರ್ಕ forceencaps ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಒಂದು ಬ್ಯಾಕೆಂಡ್‌ನ ಕೀವರ್ಡ್ ಅನ್ನು ಇನ್ನೊಂದಕ್ಕೆ ಹಾಕಿದರೆ ದೂರಿಲ್ಲದೆ ಲೋಡ್ ಆಗುವ ಮತ್ತು ಏನನ್ನೂ ಬದಲಿಸದ ಸಂರಚನೆ ಸಿಗುತ್ತದೆ, ಇದು ದೋಷಕ್ಕಿಂತ ಕೆಟ್ಟದು.

ಏನನ್ನಾದರೂ ಸಂಪಾದಿಸುವ ಮೊದಲು ಯಾವ ಡೀಮನ್ ನಿಜವಾಗಿ ಚಾಲನೆಯಲ್ಲಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಅನೇಕ ವಿತರಣೆಗಳಲ್ಲಿ ಎರಡೂ ಫೈಲ್‌ಗಳು ಇರುತ್ತವೆ ಏಕೆಂದರೆ ಒಂದು ಹಿಂದಿನ ಸ್ಥಳಾಂತರದ ಶೇಷ, ಮತ್ತು ಸಕ್ರಿಯವಾದದ್ದು ಸೇವಾ ಘಟಕ ಪ್ರಾರಂಭಿಸುವುದು. ಫೈಲ್ ಸಮಯಮುದ್ರೆಗಳಿಂದ ಊಹಿಸುವ ಬದಲು ಆ ಘಟಕವನ್ನು ಓದಿ. ಇಲ್ಲಿನ ಐದು ಸೆಕೆಂಡಿನ ಪರಿಶೀಲನೆ ಏನೂ ಲೋಡ್ ಮಾಡದ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಗಂಟೆಗಟ್ಟಲೆ ಪರೀಕ್ಷಿಸುವುದನ್ನು ತಪ್ಪಿಸುತ್ತದೆ.

ಸಂಪರ್ಕದ ಮಾಲೀಕರ ಮೂಲಕ ಬದಲಾವಣೆ ಅನ್ವಯಿಸಿ ಮತ್ತು ನಿಯಂತ್ರಿತ ಕಿಟಕಿಯಲ್ಲಿ ಸಂಘವನ್ನು ಮರುಸ್ಥಾಪಿಸಿ. ಈಗಾಗಲೇ ಸ್ಥಾಪಿಸಿದ child ಬದಲಾಯಿಸುವವರೆಗೆ ತನ್ನ ಪ್ರಸ್ತುತ ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೇವಲ ಫೈಲ್ ಸಂಪಾದನೆ ಹೊಸ ವ್ಯವಸ್ಥೆ ಬಳಕೆಯಲ್ಲಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

ಸುತ್ತಿದ ಡೇಟಾವನ್ನು ಪರಿಶೀಲಿಸಿ, ಪೋರ್ಟ್ ಮಾತ್ರವಲ್ಲ

ಸಂರಕ್ಷಿತ ಸಂಚಾರ ಹರಿಯುತ್ತಿರುವಾಗ ಗೇಟ್‌ವೇಯಲ್ಲಿ ಸೆರೆಹಿಡಿಯಿರಿ, ನಂತರ ಅದನ್ನು strongSwan ನ ಸ್ವಂತ ನೋಟದೊಂದಿಗೆ ಹೋಲಿಸಿ:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP IP ಪ್ರೋಟೋಕಾಲ್ 50 ಆಗಿ ಕಾಣುತ್ತದೆ ಮತ್ತು UDP ಗೆ ಸ್ವಲ್ಪವೂ ಹೋಲುವುದಿಲ್ಲ. ಸುತ್ತಿದ ESP 4500 ನಲ್ಲಿ UDP ಡೇಟಾಗ್ರಾಮ್‌ಗಳಾಗಿ ಕಾಣುತ್ತದೆ, ಅವುಗಳ ಪೇಲೋಡ್ IKE ಅಲ್ಲ. ಅದೇ ಪೋರ್ಟ್‌ನಲ್ಲಿ IKE ಸಂಚಾರ ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್‌ನ ಸಾಕ್ಷ್ಯವಲ್ಲ, ಏಕೆಂದರೆ MOBIKE IKE ಅನ್ನು ಅಲ್ಲಿಗೆ ಸರಿಸಬಹುದು ಮತ್ತು ಡೇಟಾ ಮಾರ್ಗ native ಆಗಿಯೇ ಇರುತ್ತದೆ, ಆದ್ದರಿಂದ ಪೋರ್ಟ್ ಸಂಖ್ಯೆಯಲ್ಲ, ಪೇಲೋಡ್ ಓದಿ.

ಮಾರ್ಗದ MTU ಅನ್ನೂ ನೆನಪಿನಲ್ಲಿಡಿ. ಆವರಣ ಹೆಚ್ಚುವರಿ ವೆಚ್ಚ ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು native ESP ಒಯ್ದ ಮಾರ್ಗ ಪ್ಯಾಕೆಟ್‌ಗಳು ದೊಡ್ಡದಾದಂತೆ ಹೊಂದಾಣಿಕೆಗಳ ಅಗತ್ಯವಿರಬಹುದು. ಅಗತ್ಯವಾದ ICMP ನಿರ್ವಹಣೆ ಈಗಾಗಲೇ ವಿನ್ಯಾಸದ ಭಾಗವಾಗಿರಬೇಕು; ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಆ ಅವಲಂಬನೆಯನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ.

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

ಸಂಬಂಧಿತ ಲೇಖನಗಳು