ನೀವು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗದ NAT ಹಿಂದಿನ VPN: ಇನ್ನೂ ಏನು ಕೆಲಸ ಮಾಡುತ್ತದೆ

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

ಮ್ಯಾಪಿಂಗ್ ಟೇಬಲ್ ಎಲ್ಲವನ್ನೂ ನಿರ್ಧರಿಸುತ್ತದೆ

ನೆಟ್ವರ್ಕ್ ವಿಳಾಸ ಅನುವಾದವು ಒಂದು ಟೇಬಲ್ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಅದರಲ್ಲಿ ಒಳಗಿನ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಎದುರು ದಾಖಲಾಗುತ್ತದೆ. ದಾಖಲೆಗೆ ಹೊಂದುವ ಪ್ರತಿಕ್ರಿಯೆಗಳು ಹಿಂದಕ್ಕೆ ಅನುವಾದವಾಗುತ್ತವೆ, ಮತ್ತು ಹೊಂದುವ ದಾಖಲೆ ಇಲ್ಲದೆ ಹೊರಗಿನಿಂದ ಬರುವ ಪ್ಯಾಕೆಟ್ಗೆ ಯಾವುದೇ ಗಮ್ಯಸ್ಥಾನವಿಲ್ಲ. ಆ ಒಂದೇ ವರ್ತನೆ ರೌಟರ್ ಹಿಂದಿನ ಶ್ರೋತೃ ಇಂಟರ್ನೆಟ್ನಿಂದ ಏಕೆ ತಲುಪಲಾಗದು ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ. ಪ್ರತಿ ದಿಕ್ಕಿನಲ್ಲೂ ಮೊದಲ ಪ್ಯಾಕೆಟ್ ಒಳಗಿನಿಂದಲೇ ಹುಟ್ಟಬೇಕು ಎಂಬುದನ್ನೂ ಅದು ವಿವರಿಸುತ್ತದೆ.

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

ರೆನ್ಡೆಜ್ವಸ್ ಸೇವೆ ಏನು ಮಾಡಬಹುದು ಮತ್ತು ಏನು ಮಾಡಲಾಗದು

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

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

ಕೀಪ್ಅಲೈವ್, ರೀಬೂಟ್ ಮತ್ತು ಚಲಿಸುವ ಎಂಡ್ಪಾಯಿಂಟ್

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

ಒಂದು ಗಂಟೆ ನಿದ್ರಿಸಿದ ಲ್ಯಾಪ್ಟಾಪ್ ಸಾಮಾನ್ಯವಾಗಿ ಬೇರೆ ಸಾರ್ವಜನಿಕ ಎಂಡ್ಪಾಯಿಂಟ್ನಲ್ಲಿ ಮರಳುತ್ತದೆ. ಮಾರ್ಗವನ್ನು ಮರುಸ್ಥಾಪಿಸುವ ಎಲ್ಲವೂ ಮತ್ತೆ ಒಳಗಿನಿಂದ ಓಡಬೇಕು, ಇದು ಅದೇ ಷರತ್ತನ್ನು ಕ್ಲೈಂಟ್ಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ.

ಕಾಣೆಯಾದ ಫಾರ್ವರ್ಡ್ ಸುತ್ತಲು ಮೂರು ದಾರಿಗಳು

ಮೊದಲ ದಾರಿ ರೌಟರ್ ತಾನೇ ನಮೂದನ್ನು ರಚಿಸಲು ಕೇಳುತ್ತದೆ, UPnP IGD, NAT-PMP ಅಥವಾ PCP ಮೂಲಕ, ವೈಶಿಷ್ಟ್ಯ ಇದ್ದು ಆನ್ ಆಗಿದ್ದಾಗ. ಎರಡನೆಯದು ಸಂಚಾರವನ್ನು ಸಾರ್ವಜನಿಕ ವಿಳಾಸವಿರುವ ರಿಲೇಗೆ ಒಪ್ಪಿಸುತ್ತದೆ, ಅದು ಯಾವಾಗಲೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಯಾವಾಗಲೂ ಬ್ಯಾಂಡ್ವಿಡ್ತ್ ಜೊತೆಗೆ ಬೇರೆ ವಿಶ್ವಾಸ ಮಿತಿಯನ್ನು ವೆಚ್ಚ ಮಾಡುತ್ತದೆ. ಮೂರನೆಯದು ದಿಕ್ಕನ್ನು ತಿರುಗಿಸುತ್ತದೆ: ಒಳಗಿನ ಹೋಸ್ಟ್ ಸಾರ್ವಜನಿಕ ಸರ್ವರ್ಗೆ ಹೊರಹೋಗುವ ಟನೆಲ್ ತೆರೆಯುತ್ತದೆ ಮತ್ತು ಉಳಿದೆಲ್ಲವೂ ಅದರೊಳಗೆ ಸವಾರಿ ಮಾಡುತ್ತದೆ.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

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

ಪರ್ಯಾಯ ಮಾರ್ಗವನ್ನು ರೌಟರ್ನ ಮಾಲೀಕರಿಗೆ ಹೊಂದಿಸಿ

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

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