ಹೇರ್ಪಿನ್ NAT: ಒಳಗಿನಿಂದ VPN ಎಂಡ್ಪಾಯಿಂಟ್ ಏಕೆ ವಿಫಲವಾಗುತ್ತದೆ

ಮೊಬೈಲ್ ನೆಟ್ವರ್ಕ್ನಿಂದ ಉತ್ತರಿಸುವ ಆದರೆ ಸೋಫಾದಿಂದ ವಿಫಲವಾಗುವ VPN ಸರ್ವರ್ ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರಮಾಣಪತ್ರದ ಸಮಸ್ಯೆ ಅಲ್ಲ. LAN ಒಳಗಿನ ಕ್ಲೈಂಟ್, ತನ್ನ ಗಮ್ಯಸ್ಥಾನವೇ ರೌಟರ್ನ ಸ್ವಂತ ಸಾರ್ವಜನಿಕ ವಿಳಾಸವಾಗಿರುವ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಭಾಷಾಂತರಿಸಲು ರೌಟರ್ಗೆ ಕೇಳುತ್ತದೆ, ಅಂದರೆ ಪ್ಯಾಕೆಟ್ ಹೊರಗೆ ಹೋಗಿ ತಕ್ಷಣ ಮರಳಿ ಒಳಗೆ ಬರಬೇಕು. ಈ ಕುಶಲತೆಗೆ ಹೇರ್ಪಿನಿಂಗ್ ಎನ್ನುತ್ತಾರೆ, ಮತ್ತು ಅನೇಕ ರೌಟರ್ಗಳು ಅದನ್ನು ಜಾರಿಗೆ ತರುವುದಿಲ್ಲ ಅಥವಾ ಚೆಕ್ ಬಾಕ್ಸ್ ಸಕ್ರಿಯವಾದಾಗ ಮಾತ್ರ ಮಾಡುತ್ತವೆ. ಹೊರಗಿನ ಪರೀಕ್ಷೆ ಯಶಸ್ವಿಯಾಗುವುದೇ ಗೊಂದಲದ ಕಾರಣ, ಏಕೆಂದರೆ ಅದು ಆಲಿಸುವವನು ಮತ್ತು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ನಿಯಮ ಸರಿಯಾಗಿವೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.

ಪ್ಯಾಕೆಟ್ ಹೊರಗೆ ಹೋಗಿ ಮರಳಿ ಒಳಗೆ ಬರುತ್ತದೆ

ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಅನುಸರಿಸಿ. ಕ್ಲೈಂಟ್ ಸಾರ್ವಜನಿಕ ಹೆಸರನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಮತ್ತು ರೌಟರ್ನ ಗಮ್ಯಸ್ಥಾನ NAT ಗಮ್ಯಸ್ಥಾನವನ್ನು ಒಳಗಿನ ಸರ್ವರ್ಗೆ ಮತ್ತೆ ಬರೆಯುತ್ತದೆ. ಸರ್ವರ್ನ ಉತ್ತರವು ಕ್ಲೈಂಟ್ನ LAN ವಿಳಾಸಕ್ಕೆ ಉದ್ದೇಶಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಅದು ಮೂಲವನ್ನು ಮರಳಿ ಭಾಷಾಂತರಿಸುತ್ತಿದ್ದ NAT ನಿಯಮವನ್ನು ಎಂದಿಗೂ ದಾಟದೆ ರೌಟರ್ನ LAN ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಮರಳುತ್ತದೆ.

ಈಗ ಕ್ಲೈಂಟ್ ತಾನು ಎಂದೂ ಏನನ್ನೂ ಕಳುಹಿಸದ ವಿಳಾಸದಿಂದ ಪ್ಯಾಕೆಟ್ ಪಡೆದು ಅದನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ. ಆ ಅಸಮಮಿತಿಯೇ ಇಡೀ ವೈಫಲ್ಯ.

RFC 4787 ಈ ಸಂದರ್ಭದಲ್ಲಿ NAT ನಿಂದ ನಿರೀಕ್ಷಿಸುವ ವರ್ತನೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಸಂಕ್ಷಿಪ್ತ ರೂಪವೆಂದರೆ ಅದು ಸಿದ್ಧಾಂತದಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ್ದರೂ ಆಚರಣೆಯಲ್ಲಿ ಐಚ್ಛಿಕ. ಕೆಲವು ರೌಟರ್ಗಳು ಈ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು NAT loopback ಎನ್ನುತ್ತವೆ, ಇನ್ನು ಕೆಲವು ಹೇರ್ಪಿನ್ NAT ಅಥವಾ NAT reflection ಎನ್ನುತ್ತವೆ, ಮತ್ತು ಕೆಲವು ಏನನ್ನೂ ತೋರಿಸುವುದಿಲ್ಲ. ಅದು ಇಲ್ಲದ ರೌಟರ್ ತಪ್ಪಾಗಿ ಸಂರಚಿಸಲ್ಪಟ್ಟಿಲ್ಲ; ಅದು ಸಾಮಾನ್ಯ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತಿದೆ, ಮತ್ತು ಪರಿಹಾರ ಬೇರೆಡೆ ಸೇರಿದೆ. ಸ್ಥಳೀಯ ಪರೀಕ್ಷೆ ವಿಫಲವಾಯಿತೆಂದು ಸಾರ್ವಜನಿಕ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ನಿಯಮ ತಪ್ಪು ಎಂದು ತೀರ್ಮಾನಿಸಬೇಡಿ.

ಪರಿಶೀಲನೆ 1: ಎರಡು ಮಾರ್ಗಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ

LAN ಹೊರಗಿನಿಂದ ನಿಜವಾದ ಬಳಕೆದಾರರು ಬಳಸುವ ಅದೇ ಪ್ರೊಫೈಲ್ನೊಂದಿಗೆ ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ಸೆಷನ್ ಸ್ಥಾಪನೆಯಾಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಒಳಗಿನಿಂದ ಅದೇ ಪ್ರೊಫೈಲ್ನೊಂದಿಗೆ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ನಿಖರವಾದ ದೋಷ ಹಾಗೂ ಸಮಯವನ್ನು ದಾಖಲಿಸಿ.

ನಿಖರವಾದ ಸ್ಥಳೀಯ ಪರೀಕ್ಷೆ ಹೋಸ್ಟ್ನಾಮ್ ಅನ್ನು ಉಳಿಸಿಕೊಂಡು ವಿಳಾಸವನ್ನು ಮಾತ್ರ ಬದಲಾಯಿಸುತ್ತದೆ: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ ವಿನಂತಿಯನ್ನು ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ, ಜೊತೆಗೆ ಸರಿಯಾದ ಸರ್ವರ್ ಹೆಸರನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ. ಇದು ಹೆಸರು ಪರಿಹಾರದ ಸಮಸ್ಯೆಯನ್ನು ಭಾಷಾಂತರದ ಸಮಸ್ಯೆಯಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಅದೇ ಹೆಸರು ಕಾಫಿ ಅಂಗಡಿಯಿಂದ ಕೆಲಸ ಮಾಡಿದಾಗ ಅವು ಸುಲಭವಾಗಿ ಗೊಂದಲಕ್ಕೀಡಾಗುತ್ತವೆ. ಕ್ಲೈಂಟ್ TCP ಸಂಪರ್ಕದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆಯೇ ಅಥವಾ ನಂತರ TLS ನಲ್ಲಿ ಎಂಬುದನ್ನು ಗಮನಿಸಿ, ಏಕೆಂದರೆ ಮೊದಲನೆಯದು ಭಾಷಾಂತರವನ್ನು ಸೂಚಿಸುತ್ತದೆ ಮತ್ತು ಎರಡನೆಯದು ಗುರುತನ್ನು ಸೂಚಿಸುತ್ತದೆ.

ಪರಿಶೀಲನೆ 2: ಸರ್ವರ್ ಏನನ್ನು ನೋಡುತ್ತದೆ ಎಂದು ಓದಿ

ಅತ್ಯಂತ ಉಪಯುಕ್ತ ಅವಲೋಕನ ಸರ್ವರ್ನ ದೃಷ್ಟಿಕೋನ. VPN ಹೋಸ್ಟ್ನಲ್ಲಿ ಕ್ಲೈಂಟ್ನ LAN ವಿಳಾಸ ಮತ್ತು ರೌಟರ್ನ LAN ವಿಳಾಸಕ್ಕೆ ಫಿಲ್ಟರ್ ಮಾಡಿದ ಕ್ಯಾಪ್ಚರ್ ಚಲಾಯಿಸಿ, ನಂತರ ಸ್ಥಳೀಯ ಪ್ರಯತ್ನವನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಏನೂ ಬರದಿದ್ದರೆ, ಪ್ಯಾಕೆಟ್ ಭಾಷಾಂತರದಿಂದ ಪಾರಾಗಲಿಲ್ಲ.

ಸಂಪರ್ಕವು ಕ್ಲೈಂಟ್ನ ವಿಳಾಸದ ಬದಲು ರೌಟರ್ನ LAN ವಿಳಾಸದಿಂದ ಬಂದರೆ, ಹೇರ್ಪಿನಿಂಗ್ ನಡೆಯುತ್ತಿದೆ ಮತ್ತು ಮೂಲವನ್ನು ಮತ್ತೆ ಬರೆಯಲಾಗಿದೆ. ಇದು ಕೆಲಸ ಮಾಡುವ ಸಂರಚನೆ, ದೋಷವಲ್ಲ.

ಪರಿಶೀಲನೆ 3: ಹೊರಗಿನ ಮಾರ್ಗವನ್ನು ಮುಟ್ಟದೆ ಸರಿಪಡಿಸಿ

ಮೂರು ಬೆಂಬಲಿತ ರೂಪಗಳಿವೆ, ಪ್ರಭಾವದ ವ್ಯಾಪ್ತಿ ಹೆಚ್ಚುವ ಕ್ರಮದಲ್ಲಿ. ಅತ್ಯಂತ ಸಂಕುಚಿತವಾದದ್ದು ವಿಭಜಿತ DNS: ಆಂತರಿಕ ದಾಖಲೆಯನ್ನು ಪ್ರಕಟಿಸಿ, ಅದೇ ಸರ್ವರ್ ಹೆಸರು LAN ನಲ್ಲಿನ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಆಂತರಿಕ ವಿಳಾಸಕ್ಕೆ ಪರಿಹಾರವಾಗುವಂತೆ ಮಾಡಿ, ಇದು ಸಾರ್ವಜನಿಕ ಮಾರ್ಗವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪಿಸುತ್ತದೆ. ಮುಂದಿನದು ರೌಟರ್ನ ದಾಖಲಿತ loopback ಅಥವಾ reflection ಆಯ್ಕೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದು, ಅದು ಇದ್ದರೆ, ಮತ್ತು ಅದನ್ನು ಈ ಸೇವೆಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುವುದು. ಅತ್ಯಂತ ವಿಶಾಲವಾದದ್ದು ರೌಟರ್ನಲ್ಲಿ source-NAT ನಿಯಮ, ಅದು LAN ನಿಂದ ಬರುವ ಸಂಚಾರವನ್ನು ಸರ್ವರ್ಗೆ ಮತ್ತೆ ಬರೆಯುತ್ತದೆ, ಇದರಿಂದ ಉತ್ತರ ರೌಟರ್ ಮೂಲಕ ಮರಳುತ್ತದೆ; Linux ರೌಟರ್ನಲ್ಲಿ ಅದು ಸರ್ವರ್ನ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ಗೆ ಹೊಂದುವ MASQUERADE ನಿಯಮ POSTROUTING ಆಗಿರುತ್ತದೆ. ಮೂರೂ ಹೊರಗಿನ ಮಾರ್ಗವನ್ನು ಮುಟ್ಟದೆ ಬಿಡುತ್ತವೆ, ಮತ್ತು ಸಂರಕ್ಷಿಸಬೇಕಾದ ಗುಣ ಅದೇ.

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

ವಿಭಜಿತ DNS ಗೆ ಒಂದು ಬಲೆ ಇದೆ, ಅದನ್ನು ಉಲ್ಲೇಖಿಸುವುದು ಯೋಗ್ಯ. ಹೋಸ್ಟ್ನಾಮ್ ಅನ್ನು ಅನಿಯಂತ್ರಿತ IP ಯೊಂದಿಗೆ ಬದಲಾಯಿಸುವುದು ಕ್ಲೈಂಟ್ ಏನನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಆಂತರಿಕ ದಾಖಲೆ ಇನ್ನೂ ಪ್ರಮಾಣಪತ್ರದ ಹೆಸರಿಗೆ ಹೊಂದಬೇಕು.

ಪರಿಶೀಲನೆ 4: ನಂತರ ಎರಡೂ ಮಾರ್ಗಗಳನ್ನು ಪರಿಶೀಲಿಸಿ

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

ದಾಖಲೆಯನ್ನು ಚಿಕ್ಕದಾಗಿ ಇರಿಸಿ: ಯಾವ ಕ್ಲೈಂಟ್ ಯಾವ ವಿಳಾಸವನ್ನು ಬಳಸಿತು, ಸರ್ವರ್ ಏನನ್ನು ನೋಡಿತು, ಮತ್ತು ಮೂರು ಪರಿಹಾರಗಳಲ್ಲಿ ಯಾವುದನ್ನು ಅನ್ವಯಿಸಲಾಯಿತು. RFC 4787 ನ ಹೇರ್ಪಿನಿಂಗ್ ಅಗತ್ಯಗಳು ಇಲ್ಲಿ NAT ನಿಂದ ಏನನ್ನು ನಿರೀಕ್ಷಿಸಲಾಗುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಉಲ್ಲೇಖ, ಮತ್ತು ಈ ವೈಶಿಷ್ಟ್ಯವಿಲ್ಲದ ರೌಟರ್ ಸಾಮಾನ್ಯವಾಗಿ ಏಕೆ ವರ್ತಿಸುತ್ತದೆ ಎಂದು ವಿವರಿಸುತ್ತವೆ. ಹೊರಗಿನ ಜಗತ್ತು ಪುನರುತ್ಪಾದಿಸಲಾಗದ ಸ್ಥಳೀಯ ವೈಫಲ್ಯವು ವಿರುದ್ಧವಾಗಿ ಸಾಬೀತಾಗುವವರೆಗೆ ಭಾಷಾಂತರದ ಪ್ರಶ್ನೆ, ಆದ್ದರಿಂದ ಅದನ್ನೇ ಹಾಗೆ ಪರೀಕ್ಷಿಸಿ.