NAT ಮೂಲಕ L2TP/IPsec: ನಿಜವಾಗಿ ಏನು ಮುರಿಯುತ್ತದೆ ಮತ್ತು ಏಕೆ

NAT L2TP/IPsec ಅನ್ನು ಮುರಿಯುತ್ತದೆ ಎಂಬ ಹೇಳಿಕೆ ಅರ್ಧ ನಿಜ ಮತ್ತು ಆದ್ದರಿಂದ ನಿಷ್ಪ್ರಯೋಜಕ. ವಿಳಾಸ ಅನುವಾದ ಸಾಮಾನ್ಯ, NAT traversal ಅದನ್ನು ದಾಟಲು ಇರುವುದೇ, ಮತ್ತು ಪ್ರತಿದಿನ ಲಕ್ಷಾಂತರ ಕ್ಲೈಂಟ್ಗಳು ರೂಟರ್ನ ಹಿಂದೆ ಸಂಪರ್ಕಿಸುತ್ತವೆ. ಮುರಿಯುವುದು ನಿರ್ದಿಷ್ಟ ವಿನಿಮಯದ ನಿರ್ದಿಷ್ಟ ಹಂತ: IKE ಎಂದಿಗೂ ಉತ್ತರ ಪಡೆಯುವುದಿಲ್ಲ, ಎನ್ಕ್ಯಾಪ್ಸುಲೇಟೆಡ್ ಟನೆಲ್ ಒಂದೇ ಪ್ರೋಟೋಕಾಲ್ಗೆ ಅನುಮತಿ ನೀಡುವ ನೀತಿಯಿಂದ ಬಿಸಾಡಲ್ಪಡುತ್ತದೆ, ಅಥವಾ ಟನೆಲ್ ನಿಷ್ಕ್ರಿಯವಾಗಿರುವಾಗ ಮ್ಯಾಪಿಂಗ್ ಮುಗಿಯುತ್ತದೆ. ನೀವು ಯಾವ ಹಂತದಲ್ಲಿದ್ದೀರಿ ಎಂದು ತಿಳಿದ ನಂತರ, ಪರಿಹಾರ ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ನಿಯಮ ಅಥವಾ keepalive, ಹೊಸ VPN ವಿನ್ಯಾಸವಲ್ಲ.

ಪುರಾಣವೇ ತಪ್ಪು ಪ್ರಶ್ನೆ

ಉಪಯುಕ್ತ ಪ್ರಶ್ನೆ “NAT ಇದನ್ನು ಮುರಿಯುತ್ತದೆಯೇ” ಅಲ್ಲ, ಬದಲಿಗೆ “ವಿನಿಮಯದ ಯಾವ ಭಾಗ ಅನುವಾದವಾಗುತ್ತದೆ, ಮತ್ತು ಅನುವಾದ ಮಾಡುವ ಸಾಧನ ಅದರೊಂದಿಗೆ ಏನು ಮಾಡುತ್ತದೆ”. L2TP/IPsec ಪದರದ ಪ್ರೋಟೋಕಾಲ್: IKE ಮಾತುಕತೆ ನಡೆಸುತ್ತದೆ, ESP ರಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು L2TP ಆ ರಕ್ಷಣೆಯ ಒಳಗೆ PPP ಸಾಗಿಸುತ್ತದೆ. ವಿಳಾಸ ಅನುವಾದ ಪ್ರತಿ ಪದರದೊಂದಿಗೆ ಬೇರೆ ರೀತಿ ವರ್ತಿಸುತ್ತದೆ, ಮತ್ತು ದೋಷ ಸಂವಾದದ ಬದಲು ಮಾತುಕತೆಯ ಹಂತವನ್ನು ನೋಡಿದರೆ ವೈಫಲ್ಯದ ಚಿಹ್ನೆಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಬಹುದು.

ಯಶಸ್ವಿಯಾಗಿ ವೆಬ್ ಬ್ರೌಸ್ ಮಾಡುವ ರೂಟರ್ ಮೂಲ ಪೋರ್ಟ್ ಅನುವಾದದೊಂದಿಗೆ TCP ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಇದು UDP 500, UDP 4500 ಅಥವಾ ಪ್ರೋಟೋಕಾಲ್ 50 ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಈ ನಿಯೋಜನೆ ಈ ಮೂರನ್ನೇ ಅವಲಂಬಿಸಿದೆ.

ಹಂತ 1: IKE ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಉತ್ತರ ಪಡೆಯಬೇಕು

ಮೊದಲ ವಿನಿಮಯ UDP 500 ನಲ್ಲಿ ಉತ್ತರದಾತನ ಬಳಿ ಹೋಗುತ್ತದೆ. ಯಾವುದೇ ಉತ್ತರ ಹಿಂತಿರುಗದಿದ್ದರೆ, ಬೇರೆ ಯಾವುದೂ ಮುಖ್ಯವಲ್ಲ: ಪೂರ್ವ-ಹಂಚಿಕೆಯ ಕೀ, ಪ್ರಸ್ತಾವನೆ ಮತ್ತು ರುಜುವಾತುಗಳು ಓದದೆಯೇ ಉಳಿಯುತ್ತವೆ. ಕ್ಲೈಂಟ್ನ ಟೈಮೌಟ್ನಿಂದ ಊಹಿಸುವ ಬದಲು ವಿನಂತಿ ಮತ್ತು ಉತ್ತರವನ್ನು ಗಮನಿಸಿ:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

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

ಎರಡೂ ಕಡೆ ಅನುವಾದದ ಹಿಂದೆ ಇದ್ದರೆ, ಆರಂಭಿಸುವವನು ಉತ್ತರದಾತನನ್ನು ತಲುಪಿದರೆ ಸಾಕು, ಆದ್ದರಿಂದ ಬಹುಪಾಲು ಕ್ಲೈಂಟ್-ಬದಿಯ ನಿಯೋಜನೆಗಳು ಹಂತ 1 ರಿಂದ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಸರ್ವರ್-ಬದಿಯ ಹೋಸ್ಟಿಂಗ್ ಎಂಬುದು ಒಳಬರುವ ಸಮಸ್ಯೆ ಪ್ರಾರಂಭವಾಗುವ ಸ್ಥಳ, ಮತ್ತು ಆದ್ದರಿಂದ ಈ ಎರಡು ಸನ್ನಿವೇಶಗಳನ್ನು ಎಂದಿಗೂ ಒಂದೆಂದು ಚರ್ಚಿಸಬಾರದು.

ಹಂತ 2: ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಫೈರ್ವಾಲ್ ನೋಡುವುದನ್ನು ಬದಲಿಸುತ್ತದೆ

ESP ಒಂದು IP ಪ್ರೋಟೋಕಾಲ್, TCP ಅಥವಾ UDP ಪೋರ್ಟ್ ಅಲ್ಲ, ಮತ್ತು ಸಾಮಾನ್ಯ ಪೋರ್ಟ್ ವಿಳಾಸ ಅನುವಾದದಲ್ಲಿ ಮತ್ತೆ ಬರೆಯಲು ಪೋರ್ಟ್ ಕ್ಷೇತ್ರವಿಲ್ಲ. ಆದ್ದರಿಂದ NAT traversal ರಕ್ಷಿತ ಪೇಲೋಡ್ ಅನ್ನು UDP 4500 ಗೆ ಸರಿಸುತ್ತದೆ: ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಅನುವಾದಿಸುವ ಸಾಧನಕ್ಕೆ ಅದು ಅನುವಾದಿಸಲು ತಿಳಿದಿರುವುದನ್ನು ನೀಡುತ್ತದೆ. ಹಾಗಾದ ನಂತರ, UDP 500 ಗೆ ಮಾತ್ರ ಬರೆದ ಫೈರ್ವಾಲ್ ನಿಯಮ ಮಾತುಕತೆಗೆ ಅನುಮತಿ ನೀಡಿ ಟನೆಲ್ ಅನ್ನು ಬಿಸಾಡುತ್ತದೆ, ಇದು ಲಾಗ್ ಯಶಸ್ವಿ ಹಂತ 1 ಮತ್ತು ಯಾವುದೇ ಸಂಚಾರವಿಲ್ಲ ಎಂದು ತೋರಿಸುವ ಗೊಂದಲದ ಫಲಿತಾಂಶ ನೀಡುತ್ತದೆ.

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

ಪ್ರೋಟೋಕಾಲ್ 50 ಅನುವಾದವಿಲ್ಲದ ಮಾರ್ಗಗಳಲ್ಲಿ ಮತ್ತು ಮಧ್ಯವರ್ತಿ ಬಾಕ್ಸ್ ಅದಕ್ಕೆ ಅನುಮತಿ ನೀಡಲು ಸಂರಚಿಸಲಾದ ಮಾರ್ಗಗಳಲ್ಲಿ ಇನ್ನೂ ಮುಖ್ಯ. ನೀವು ತೆಗೆದುಹಾಕುವ ಮೂಲಕ ರೋಗನಿರ್ಣಯ ಮಾಡುತ್ತಿದ್ದರೆ, ನಿಯಮಗಳನ್ನು ರಾಶಿಯಾಗಿ ಸೇರಿಸುವ ಬದಲು ಊಹೆಯನ್ನು ಆಫ್ ಮಾಡಿ: 500, 4500 ಮತ್ತು ESP ಗೆ ಅನುಮತಿ ನೀಡಿ, ಟನೆಲ್ ಏರುವುದನ್ನು ಖಚಿತಪಡಿಸಿ, ನಂತರ ಅನಗತ್ಯವೆಂದು ಸಾಬೀತಾದದ್ದನ್ನು ತೆಗೆಯಿರಿ. ಯಾರೂ ವಿವರಿಸಲಾಗದ ನಿಯಮವು ಮುಂದಿನ ಅಡಚಣೆಯ ಕಾರಣವಾದಾಗ ಯಾರೂ ತೆಗೆಯದ ನಿಯಮ. ಸಂಕೋಚನವನ್ನು ಬದಲಾವಣೆ ದಾಖಲೆಯಲ್ಲಿ ಸರಿಪಡಿಸಿದ ಹಂತದೊಂದಿಗೆ ಬರೆಯಿರಿ, ಮುಂದಿನ ಇಂಜಿನಿಯರ್ ಅದೇ ಅಂಗುಷ್ಠ ನಿಯಮದಿಂದಲ್ಲ, ನಿಮ್ಮ ಸಾಕ್ಷ್ಯದಿಂದ ಪ್ರಾರಂಭಿಸಲಿ.

ಹಂತ 3: ಮ್ಯಾಪಿಂಗ್ ಮುಗಿಯುತ್ತದೆ ಮತ್ತು ಟನೆಲ್ ಸಾಯುತ್ತದೆ

ಅನುವಾದಿಸುವ ಸಾಧನವು ರವಾನಿಸುವ ಹರಿವುಗಳಿಗೆ ಸ್ಥಿತಿಯನ್ನು ಇಡುತ್ತದೆ, ಮತ್ತು ಆ ಸ್ಥಿತಿಗೆ ಆಯುಷ್ಯವಿದೆ. ಯಾರೂ ಬಳಸದಿದ್ದಾಗ L2TP/IPsec ಟನೆಲ್ ಕಡಿಮೆ ಸಂಚಾರ ಸಾಗಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಷ್ಕ್ರಿಯ ಟನೆಲ್ ತನ್ನ ಮ್ಯಾಪಿಂಗ್ಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಬದುಕಿ ಹಿಂತಿರುಗುವ ಸಂಚಾರವನ್ನು ಪಡೆಯುವುದನ್ನು ನಿಲ್ಲಿಸಬಹುದು. ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕದಲ್ಲಿದೆ ಎಂದು ನಂಬಿರುತ್ತದೆ, ಸರ್ವರ್ ಏನನ್ನೂ ಕಾಣುವುದಿಲ್ಲ, ಮತ್ತು ಮೊದಲ ಲಕ್ಷಣ ಸಾಮಾನ್ಯವಾಗಿ VPN ದೋಷವಲ್ಲ, ಅಪ್ಲಿಕೇಶನ್ ಟೈಮೌಟ್.

ಸತ್ತ ಪೀರ್ ಪತ್ತೆ ಮತ್ತು NAT keepalive ಇದಕ್ಕಾಗಿಯೇ ಇವೆ, ಮತ್ತು ಎರಡೂ ತುದಿಗಳು ಅವನ್ನು ಕಳುಹಿಸಲು ಸಿದ್ಧವಿರಬೇಕು. ನಿಮ್ಮ ಸರ್ವರ್ ಅನುವಾದದ ಹಿಂದೆ ಇದ್ದರೆ, Windows ಬದಿಯ ಅಗತ್ಯವೆಂದರೆ ಸರ್ವರ್ ತನ್ನ ಸ್ವಂತ ಹೊರಹೋಗುವ ಪ್ಯಾಕೆಟ್ಗಳಿಗೆ UDP ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಊಹಿಸುವಂತೆ ಮಾಡುವ ದಾಖಲಿತ ರಿಜಿಸ್ಟ್ರಿ ಸೆಟ್ಟಿಂಗ್; ಅದಿಲ್ಲದೆ ಉತ್ತರದಾತ ಅನುವಾದಿಸುವ ಸಾಧನವು ಹಿಂತಿರುಗಿಸಲಾಗದ ESP ಕಳುಹಿಸುತ್ತದೆ. ಇದು ಸರ್ವರ್ ಸಂರಚನೆಯ ವಿಷಯ, ಕ್ಲೈಂಟ್ನದಲ್ಲ.

WAN ವಿಳಾಸ ಬದಲಾದರೆ ಬೇರೆ ದಿಕ್ಕಿನಿಂದ ಅದೇ ಫಲಿತಾಂಶ: ಮ್ಯಾಪಿಂಗ್ ಹೊಸ ವಿಳಾಸದ ಸುತ್ತ ಮತ್ತೆ ನಿರ್ಮಾಣವಾಗುತ್ತದೆ, ಮತ್ತು ಹಳೆಯ ಭದ್ರತಾ ಸಂಘವು ಈಗ ಇಲ್ಲದ ಜೋಡಿಗೆ ತೋರಿಸುತ್ತದೆ. ಮರುಸಂಪರ್ಕದ ವರ್ತನೆ ಕ್ಲೈಂಟ್ ಅನುಷ್ಠಾನಕ್ಕೆ ಸೇರಿದ್ದು, ಆದ್ದರಿಂದ “ರೂಟರ್ ಮರುಪ್ರಾರಂಭದ ನಂತರ ಮತ್ತೆ ಸಂಪರ್ಕಿಸು” ಒಂದು ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಇನ್ನೊಂದರಲ್ಲಿ ಕೈಯಿಂದ ಟಾಗಲ್ ಬೇಕು.

ಕ್ಯಾರಿಯರ್-ಗ್ರೇಡ್ NAT ಹಿಂದೆ ಹೋಸ್ಟಿಂಗ್ ಬೇರೆ ಸಮಸ್ಯೆ

ನೀವು ಮನೆಯಲ್ಲಿ L2TP/IPsec ಸರ್ವರ್ ಹೋಸ್ಟ್ ಮಾಡಿ ಹೊರಗಿನಿಂದ ಅದನ್ನು ತಲುಪಲು ಬಯಸಿದರೆ, ಅಗತ್ಯವೆಂದರೆ ಕೇಳದ ಒಳಬರುವ ತಲುಪುವಿಕೆ, ಮತ್ತು ಅದು NAT traversal ನೀಡುವುದಲ್ಲ. ನಿಮ್ಮ ರೂಟರ್ ಮುಂದೆ ಕ್ಯಾರಿಯರ್-ಗ್ರೇಡ್ NAT ಇದ್ದರೆ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಹಂಚಿಕೆಯಾಗಿರುವುದರಿಂದ ಮತ್ತು ಮ್ಯಾಪಿಂಗ್ ಹೊರಹೋಗುವಿಕೆ ಮಾತ್ರವಾದ್ದರಿಂದ, ನಿಮ್ಮನ್ನು ತಲುಪಬಹುದಾದಂತೆ ಮಾಡುವ ಯಾವುದೇ ಪೋರ್ಟ್ ಇಲ್ಲ.

ಯಾವುದೇ IPsec ಪಾಸ್-ಥ್ರೂ ಚೆಕ್ಬಾಕ್ಸ್ ಇದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಯಾವುದೇ ಕ್ಲೈಂಟ್ ಸಂರಚನೆ ಇದನ್ನು ಸರಿದೂಗಿಸುವುದಿಲ್ಲ. ಬೆಂಬಲಿತ ಉತ್ತರಗಳೆಂದರೆ ನಿಜವಾಗಿ ತಲುಪಬಹುದಾದ ವಿಳಾಸ, ಹೋಸ್ಟ್ ಮಾಡಿದ ಅಂತಿಮ ಬಿಂದು, ಅಥವಾ ಪ್ರತಿಯೊಬ್ಬ ಭಾಗೀದಾರ ಹೊರಹೋಗುವ ಸಂಪರ್ಕ ಮಾಡುವ ಆರ್ಕಿಟೆಕ್ಚರ್. UDP ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ವಿಶೇಷಣ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಹರಿವುಗಳಿಗೆ ಅನುವಾದ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ; ಕ್ಯಾರಿಯರ್ ನೀಡದಿರುವಲ್ಲಿ ಅದು ಒಳಬರುವ ಮಾರ್ಗವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ.

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