L2TP/IPsec ಗೆ IPsec ಜೊತೆಗೆ UDP 1701 ಏಕೆ ಬೇಕು

IKE ಮತ್ತು ESP ಅನ್ನು ಅನುಮತಿಸಿ UDP 1701 ಅನ್ನು ಅನುಮತಿಸದ ಫೈರ್ವಾಲ್ಗಳು L2TP ಸಂಪರ್ಕಗಳನ್ನು ರುಜುವಾತುಗಳ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುವ ರೀತಿಯಲ್ಲಿ ಮುರಿಯುತ್ತವೆ. ಕಾರಣ L2TP ಮೊದಲನೆಯ ಒಳಗೆ ಚಲಿಸುವ ಎರಡನೆಯ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದೆ. IPsec ವಿನಿಮಯವನ್ನು ಸಾಗಿಸಿ ದೃಢೀಕರಿಸುತ್ತದೆ, ಮತ್ತು L2TP UDP 1701 ಮೇಲೆ ತನ್ನದೇ ಸುರಂಗವನ್ನು ನಡೆಸುತ್ತದೆ, ಅದನ್ನು ಸ್ಥಳೀಯ ಸ್ಟಾಕ್ ಇನ್ನೂ ತಲುಪಿಸಬೇಕು. ಪ್ರತಿ ಹೆಡರ್ ಎಲ್ಲಿ ಕಾಣಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತಿಳಿದರೆ ಯಾವ ಸಾಧನಕ್ಕೆ ಯಾವ ನಿಯಮ ಬೇಕು ಎಂದು ವಿವರಿಸುತ್ತದೆ.

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

L2TP/IPsec ಸಂಪರ್ಕವು UDP 500 ನಲ್ಲಿ IKE, ಅನುವಾದ ಇರುವಲ್ಲಿ UDP 4500 ನಲ್ಲಿ NAT ಟ್ರಾವರ್ಸಲ್, ಮತ್ತು ಇಲ್ಲದಲ್ಲಿ IP ಪ್ರೋಟೋಕಾಲ್ 50 ಆಗಿ ESP ಬಳಸುತ್ತದೆ. L2TP ಸ್ವತಃ UDP 1701 ನಲ್ಲಿನ ಸುರಂಗ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದ್ದು, IPsec ಸಹಚರನನ್ನು ದೃಢೀಕರಿಸಿದ ನಂತರ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಎರಡು ಅರ್ಧಗಳು ಬೇರೆ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ, ಮತ್ತು ಅವುಗಳ ಬಗ್ಗೆ ವರದಿ ಮಾಡುವ ಲಾಗ್ ಸಾಲುಗಳು ಬೇರೆ ಬೇರೆ ಘಟಕಗಳಿಂದ ಬರುತ್ತವೆ. ಮೊದಲ ಅರ್ಧವನ್ನು ಮಾತ್ರ ಒಳಗೊಳ್ಳುವ ನಿಯಮ ಸೆಟ್ ಮಾತುಕತೆ ನಡೆಸಿ ನಂತರ ಸುರಂಗ ಹಂತದಲ್ಲಿ ಸಾಯುವ ಸಂಪರ್ಕವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

ಪೋರ್ಟ್ ಸಂಖ್ಯೆಗಳು ಸಾಗಣೆಯ ತುದಿ ಬಿಂದುಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ, ಮತ್ತು ESP ಪೋರ್ಟ್ನೇ ಅಲ್ಲ. ಆದ್ದರಿಂದ TCP ಮತ್ತು UDP ನಿಯಮಗಳನ್ನು ಮಾತ್ರ ನೀಡುವ ಫೈರ್ವಾಲ್ ಇಂಟರ್ಫೇಸ್ ಪೂರ್ಣ IPsec ನೀತಿಯನ್ನು ವ್ಯಕ್ತಪಡಿಸಲಾರದು. ಪ್ರೋಟೋಕಾಲ್ 50 ಅನ್ನು ಪ್ರೋಟೋಕಾಲ್ ಆಗಿ ಅನುಮತಿಸಬೇಕು, ಮತ್ತು UDP ಅನ್ನು ಮಾತ್ರ ಉಲ್ಲೇಖಿಸುವ ನಿಯಮ ಅದಕ್ಕೆ ಎಂದಿಗೂ ಹೊಂದಿಕೆಯಾಗದು.

ಆವರಣವೇ ಪೋರ್ಟ್ ಅನ್ನು ವಿವರಿಸುತ್ತದೆ

ತಂತಿಯ ಮೇಲೆ, L2TP/IPsec ಸಂಪರ್ಕವು ಸಾಮಾನ್ಯವಾಗಿ 500 ನಲ್ಲಿ IKE ಮತ್ತು 4500 ನಲ್ಲಿ ಸುತ್ತಿದ ESP ತೋರಿಸುತ್ತದೆ. UDP 1701 ಹೆಡರ್ ಸಂರಕ್ಷಿತ ಪೇಲೋಡ್ ಒಳಗೆ ಇರುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೊರಗಿನ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಸೆರೆಹಿಡಿಯುವುದು ಅದನ್ನು ತೋರಿಸುವುದಿಲ್ಲ. ಸ್ಥಳೀಯ ಹೋಸ್ಟ್ ಆ ಡೇಟಾಗ್ರಾಮ್ ಅನ್ನು L2TP ಡೀಮನ್ಗೆ ಇನ್ನೂ ತಲುಪಿಸಬೇಕು, ಮತ್ತು ತಲುಪಿಸುವುದು ಡೀಕ್ಯಾಪ್ಸುಲೇಶನ್ ನಂತರ ನಡೆಯುತ್ತದೆ. ಆದ್ದರಿಂದ 1701 ನಿಯಮ ಎಂಡ್ಪಾಯಿಂಟ್ನ ಸ್ವಂತ ಫೈರ್ವಾಲ್ಗೇ ಸೇರಿದೆ, ಯಾವುದೇ ಮಧ್ಯವರ್ತಿ ಸಾಧನ ಆ ಪೋರ್ಟ್ ಅನ್ನು ಎಂದಿಗೂ ನೋಡದಿದ್ದರೂ ಸಹ.

ಸಂಸ್ಕರಣೆಯ ಕ್ರಮವು ಗೊಂದಲದ ಬಹುಪಾಲನ್ನು ವಿವರಿಸುತ್ತದೆ. ಸ್ಟಾಕ್ ಹೋಸ್ಟ್ ಫಿಲ್ಟರ್ಗಿಂತ ಮೊದಲು IPsec ನೀತಿಯನ್ನು ಅನ್ವಯಿಸಿದರೆ, ಡೀಕ್ಯಾಪ್ಸುಲೇಟೆಡ್ L2TP ಪ್ಯಾಕೆಟ್ UDP 1701 ಆಗಿ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ; ಕ್ರಮವು ತಿರುವು ಮುರುವಾಗಿದ್ದರೆ, ನಿಯಮ ಸೆಟ್ ಹೊರಗಿನ ಪೋರ್ಟ್ಗಳನ್ನು ನೋಡುತ್ತದೆ. ಎರಡೂ ವರ್ತನೆಗಳು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಇವೆ, ಆದ್ದರಿಂದ ಅದೇ ನಿಯಮ ಸೆಟ್ ಒಂದು ಪ್ಲಾಟ್ಫಾರ್ಮ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ ಇನ್ನೊಂದರಲ್ಲಿ ವಿಫಲವಾಗುವಂತೆ ಕಾಣುತ್ತದೆ.

ಕ್ರಮವಾಗಿ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ

ಮೊದಲು ಹೊರಗಿನ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಸೆರೆಹಿಡಿದು IKE ಮತ್ತು ಸುತ್ತಿದ ESP ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಚಲಿಸುತ್ತಿವೆ ಎಂದು ದೃಢೀಕರಿಸಿ. ನಂತರ ಡೀಕ್ಯಾಪ್ಸುಲೇಟೆಡ್ ಟ್ರಾಫಿಕ್ಗಾಗಿ ಸ್ಥಳೀಯ ಫೈರ್ವಾಲ್ ಕೌಂಟರ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಕ್ರಮ ಮುಖ್ಯ, ಏಕೆಂದರೆ ಏನನ್ನೂ ತೋರಿಸದ ಸೆರೆಹಿಡಿಯುವಿಕೆ ಎಂದರೆ ಸಮಸ್ಯೆ ಹೋಸ್ಟ್ನ ಮೇಲ್ಭಾಗದಲ್ಲಿದೆ ಎಂದರ್ಥ.

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

ಸೆರೆಹಿಡಿಯುವಿಕೆ ವಿನಿಮಯದ ಮೊದಲ ಅರ್ಧವನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಸಹಚರ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ನಿಯಮ ಪಟ್ಟಿ 1701 ನಿಯಮ ಇದೆಯೇ ಮತ್ತು ಯಾವುದೇ ಬಿಡುಗಡೆ ನೀತಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಎಲ್ಲಿ ನಿಂತಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಸಾಕೆಟ್ ಪಟ್ಟಿ L2TP ಡೀಮನ್ ಬದ್ಧವಾಗಿದೆ ಮತ್ತು ಕೇಳುತ್ತಿದೆ ಎಂದು ದೃಢೀಕರಿಸುತ್ತದೆ, ಇದು ಎಂದಿಗೂ ಪ್ರಾರಂಭವಾಗದ ಸೇವೆಯನ್ನು ಹೊರಗಿಡುತ್ತದೆ. ನಿಯಮ ಬದಲಿಸುವ ಮೊದಲು ಮೂರನ್ನೂ ಓದಿ, ಏಕೆಂದರೆ ಕೇಳುಗನ ಅನುಪಸ್ಥಿತಿ ಮತ್ತು ಫಿಲ್ಟರ್ ಮಾಡಿದ ಪೋರ್ಟ್ ಬಳಕೆದಾರರಿಂದ ಒಂದೇ ದೂರನ್ನು ತರುತ್ತವೆ.

ಪೋರ್ಟ್ ಸ್ಕ್ಯಾನ್ ಏನನ್ನು ತೋರಿಸಲಾರದು

ಸರಿಯಾಗಿ ಸಂರಚಿಸಿದ ಸರ್ವರ್ ವಿರುದ್ಧ UDP 1701 ನ ಹೊರಗಿನ ಸ್ಕ್ಯಾನ್ ಸಾಮಾನ್ಯವಾಗಿ ಏನನ್ನೂ ವರದಿ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಅದೇ ನಿರೀಕ್ಷಿತ ಫಲಿತಾಂಶ. ಪೋರ್ಟ್ ಇಂಟರ್ನೆಟ್ಗೆ ಒಡ್ಡಿಲ್ಲ; IPsec ಸಹಚರನನ್ನು ದೃಢೀಕರಿಸಿದ ನಂತರವೇ ಅದನ್ನು ತಲುಪಬಹುದು. ಮುಚ್ಚಿದ ಫಲಿತಾಂಶವನ್ನು ದೋಷವೆಂದು ಪರಿಗಣಿಸಿದರೆ ಮುಚ್ಚಿದ್ದೇ ಇರಬೇಕಾದ ಪೋರ್ಟ್ ತೆರೆಯುತ್ತದೆ. ಸ್ಕ್ಯಾನ್ ಸುರಂಗದ ಒಳಗೆ ನೋಡಲಾರದಂತೆಯೇ ಅಪ್ಲಿಕೇಶನ್ ಟ್ರಾಫಿಕ್ ಅನ್ನೂ ನೋಡಲಾರದು.

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