NAT ಹಿಂದೆ SoftEther: ನೇರ ಟ್ರಾವರ್ಸಲ್ ಅಥವಾ VPN Azure ರಿಲೇ?

ನಿಮ್ಮ SoftEther ಸರ್ವರ್ ನೀವು ಬದಲಾಯಿಸಲಾಗದ ಪೂರೈಕೆದಾರರ ರೌಟರ್‌ನ ಹಿಂದೆ ಇದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗಳು ಇನ್ನೂ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತವೆ, ಆದ್ದರಿಂದ ರಿಲೇ ಎಲ್ಲವನ್ನೂ ಸಾಗಿಸುತ್ತದೆ ಎಂದು ನೀವು ಊಹಿಸುತ್ತೀರಿ. ಅದು ನಿಜವೇ ಎಂಬುದು ಯಾವ ಕಾರ್ಯವಿಧಾನ ಕೆಲಸ ಮಾಡಿತು ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿದೆ: DNS ಹೆಸರು, ಸಂಯೋಜಿತ UDP ಮಾರ್ಗ ಅಥವಾ ರಿಲೇಗೆ ಹೊರಹೋಗುವ ಸುರಂಗ. ಮೂರೂ ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್ ಉತ್ಪಾದಿಸಬಹುದು, ಮತ್ತು ಅವು ಬೇರೆ ಬೇರೆ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ. ಬಳಕೆದಾರರು ಅಥವಾ ಹಬ್‌ಗಳನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ನೀವು ಯಾವ ಮಾರ್ಗವನ್ನು ಖರೀದಿಸುತ್ತೀರಿ ಎಂದು ನಿರ್ಧರಿಸಿ.

ಮೂರು ಕಾರ್ಯವಿಧಾನಗಳು, ಮೂರು ವಿಭಿನ್ನ ಭರವಸೆಗಳು

ಕ್ರಿಯಾಶೀಲ DNS ಎಂದರೆ ನಾಮಕರಣ. ಅದು ಹೋಸ್ಟ್ ಹೆಸರನ್ನು ಬದಲಾಗುವ ವಿಳಾಸದ ಕಡೆಗೆ ಇರಿಸುತ್ತದೆ, ಜನರು ಸಂಖ್ಯೆಯ ಹಿಂದೆ ಓಡುವುದನ್ನು ನಿಲ್ಲಿಸಲು, ಮತ್ತು ಬೇರೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ. ಸ್ಥಳೀಯ NAT ಟ್ರಾವರ್ಸಲ್ ಎಂದರೆ ಸಮನ್ವಯ: ಎರಡು SoftEther ಅಂತ್ಯಬಿಂದುಗಳು ಮಾಹಿತಿ ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಅವುಗಳ ನಡುವಿನ ಅನುವಾದ ಸಾಧನಗಳ ಮೂಲಕ ಬಳಸಬಹುದಾದ UDP ಮಾರ್ಗವನ್ನು ತೆರೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತವೆ. VPN Azure ಒಂದು ರಿಲೇ: ಸರ್ವರ್ ಸೇವೆಗೆ ಹೊರಕ್ಕೆ ಡಯಲ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗಳು ರಿಲೇಯ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿನ ಹೋಸ್ಟ್ ಹೆಸರಿನ ಮೂಲಕ ಬರುತ್ತವೆ.

ಮೂರೂ ಒಂದೇ ವೈಶಿಷ್ಟ್ಯದ ಆವೃತ್ತಿಗಳಲ್ಲ, ಪರಸ್ಪರ ಪೂರಕ. ನಿಯೋಜನೆ ನಾಮಕರಣವನ್ನು ಬಳಸಬಹುದು ಆದರೆ ಅದರ ಸಂಪರ್ಕ ವಾಸ್ತವವಾಗಿ ಟ್ರಾವರ್ಸಲ್ ಅಥವಾ ರಿಲೇಯನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.

ಕ್ಲೈಂಟ್ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ನಿರ್ಧರಿಸಿ

ಆಯ್ಕೆ ಕ್ಲೈಂಟ್‌ನಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಟ್ರಾವರ್ಸಲ್ ಸ್ಥಳೀಯ SoftEther ಸಂಪರ್ಕ ವಿಧಾನದಲ್ಲಿ ಮಾತ್ರ ಇರುತ್ತದೆ. ಅದೇ ಸರ್ವರ್‌ನಲ್ಲಿನ OpenVPN, L2TP/IPsec ಮತ್ತು SSTP ಕೇಳುಗರು ಅದನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುವುದಿಲ್ಲ, ಒಂದು ಹೋಸ್ಟ್ ಹಂಚಿಕೊಂಡರೂ. ಬಳಕೆದಾರ ಏನನ್ನು ಚಲಾಯಿಸುತ್ತಾರೆ, ನಂತರ ನೆಟ್‌ವರ್ಕ್ ಏನನ್ನು ಅನುಮತಿಸುತ್ತದೆ ಎಂದು ನೋಡಿ. TCP 443 ಅನ್ನು ಮಾತ್ರ ಅನುಮತಿಸುವ ಕಾರ್ಪೊರೇಟ್ ನೆಟ್‌ವರ್ಕ್ ಆ ಪೋರ್ಟ್‌ನಲ್ಲಿನ ರಿಲೇ ಕಡೆಗೆ ನಿಮ್ಮನ್ನು ತಳ್ಳುತ್ತದೆ, ಆದರೆ ಟ್ರಾವರ್ಸಲ್‌ಗೆ ಬೇಕಾದ UDP ಪೋರ್ಟ್‌ಗಳನ್ನು ಹಾದುಹೋಗಲು ಬಿಡುವ ನೆಟ್‌ವರ್ಕ್ ನೇರ ಮಾರ್ಗವನ್ನು ಪ್ರಯತ್ನಿಸಬಹುದು; ಎರಡನ್ನೂ ನಿಜವಾದ ನಿರ್ಗಮನ ನೀತಿಯ ವಿರುದ್ಧ ಪರಿಶೀಲಿಸಿ.

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

ಸೆಷನ್ ಯಾವ ಸಾರಿಗೆಯನ್ನು ಆಯ್ಕೆಮಾಡಿತು ಎಂದು ಖಚಿತಪಡಿಸಿ

ಸಂಪರ್ಕ ಸ್ಥಿತಿಯೇ ಬಳಸುತ್ತಿರುವ ಮಾರ್ಗಕ್ಕೆ ಏಕೈಕ ಪ್ರಾಮಾಣಿಕ ಮೂಲ. ಅದನ್ನು ಸರ್ವರ್‌ನಲ್ಲಿ ಓದಿ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಪಡೆದ ಹೋಸ್ಟ್ ಹೆಸರನ್ನು ಪರಿಹರಿಸಿ.

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

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

ಆಯ್ಕೆಮಾಡಿದ ಮಾರ್ಗ ಯಾವುದನ್ನು ಅವಲಂಬಿಸಿದೆ ಎಂದು ಯೋಜಿಸಿ

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

ಹೋಸ್ಟ್ ಹೆಸರು, ಪ್ರೋಟೋಕಾಲ್, ವೈಶಿಷ್ಟ್ಯದ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಮತ್ತು ಗಮನಿಸಿದ ಸಾರಿಗೆಯನ್ನು ಬರೆಯಿರಿ. ಆ ನಾಲ್ಕು ಭಾಗದ ದಾಖಲೆಯೇ ಮುಂದಿನ ವ್ಯಕ್ತಿಗೆ ಕೆಲಸ ಮಾಡುವ ಸಂಪರ್ಕವನ್ನು ಮರುಸೃಷ್ಟಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.