ನಿಮ್ಮ VPN ಸುರಂಗದ ವಿಳಾಸ ಒಳಬರುವ ಪೋರ್ಟ್ ಏಕೆ ತೆರೆಯುವುದಿಲ್ಲ
ಸುರಂಗದ ವಿಳಾಸವು ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಅನ್ನು ಅಲ್ಲಿಗೆ ಮಾರ್ಗನಿರ್ದೇಶಿಸಬಲ್ಲ ಸಹವರ್ತಿಗಳಿಗೆ ಗುರುತಿಸುತ್ತದೆ ಮತ್ತು ಎಂದಿಗೂ ಶ್ರೋತೃವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ. ಬೈಂಡ್, ಹಿಂತಿರುಗುವ ಮಾರ್ಗ, ನಂತರ ನೀತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ.
ಕಚೇರಿ VPN ಗೆ ಸಂಪರ್ಕಿಸಿ, ಪೋರ್ಟ್ 8443 ನಲ್ಲಿ ಸಣ್ಣ ಸೇವೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿ, ಸುರಂಗದ ವಿಳಾಸವನ್ನು ಸಹೋದ್ಯೋಗಿಗೆ ಕಳುಹಿಸಿ ಮತ್ತು ಕ್ಲೈಂಟ್ ಇನ್ನೂ ಸಂಪರ್ಕಿತವಾಗಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತಿರುವಾಗ ಸಂಪರ್ಕ ವಿಫಲವಾಗುವುದನ್ನು ನೋಡಿ. ಸುರಂಗದಲ್ಲಿ ಏನೂ ಮುರಿದಿಲ್ಲ: ವಿಳಾಸವನ್ನು ನೀಡಲಾಗಿದೆ, ಅಧಿವೇಶನ ಸಕ್ರಿಯವಾಗಿದೆ, ಮತ್ತು ಉತ್ತರವನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತಿದ್ದ ಪ್ಯಾಕೆಟ್‌ಗಳು ಸರಳವಾಗಿ ಎಂದಿಗೂ ಅನುಮತಿಸಲ್ಪಡುವುದಿಲ್ಲ. ಕೆಳಗಿನ ಮೂರು ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ ಮತ್ತು ವಿಫಲವಾದುದರಲ್ಲಿ ನಿಲ್ಲಿಸಿ, ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದಕ್ಕೂ ಬೇರೆ ಪರಿಹಾರವಿದೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಒಂದು VPN ಗೆ ಸಂಬಂಧಿಸಿದೆ.
ಸಾಕೆಟ್ ನಿಜವಾಗಿ ಎಲ್ಲಿ ಬೈಂಡ್ ಆಗಿದೆ ಎಂಬುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ
ಏನನ್ನಾದರೂ ಮಾರ್ಗನಿರ್ದೇಶಿಸುವ ಮೊದಲು, ಕರೆ ಮಾಡುವವರು ತಲುಪಬಲ್ಲ ವಿಳಾಸದಲ್ಲಿ ಏನಾದರೂ ಕೇಳಬೇಕು. ಅಭಿವೃದ್ಧಿ ಸರ್ವರ್‌ಗಳು ಸಾಮಾನ್ಯ ಅಪರಾಧಿಗಳು, ಏಕೆಂದರೆ ಅವುಗಳಲ್ಲಿ ಹಲವು ಡೀಫಾಲ್ಟ್ ಆಗಿ loopback ಗೆ ಬೈಂಡ್ ಆಗುತ್ತವೆ ಮತ್ತು ಅದೇ ಯಂತ್ರದಿಂದ ಬರುವ ಸಂಪರ್ಕಗಳನ್ನು ಮಾತ್ರ ಸ್ವೀಕರಿಸುತ್ತವೆ. ಸುರಂಗದ ವಿಳಾಸವು ಆ ಬೈಂಡಿಂಗ್ ಅನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ, ಮತ್ತು VPN ಒಳಗೊಳ್ಳುವ ಬಹಳ ಮೊದಲೇ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಸಂಪರ್ಕವನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ.
ss -ltnp | grep 8443
netstat -ano | findstr 8443ಸ್ಥಿತಿಯಲ್ಲ, ಸ್ಥಳೀಯ ವಿಳಾಸ ಕಾಲಮ್ ಓದಿ. 127.0.0.1:8443 ಎಂದರೆ loopback ಮಾತ್ರ, ಮತ್ತು ಪರಿಹಾರ 0.0.0.0 ಅಥವಾ ಸುರಂಗದ ವಿಳಾಸಕ್ಕೇ ಬೈಂಡ್ ಮಾಡುವುದು. 0.0.0.0:8443 ಎಲ್ಲಾ ಇಂಟರ್ಫೇಸ್‌ಗಳಲ್ಲಿ ಸ್ವೀಕರಿಸುತ್ತದೆ, ಇದು ಯಂತ್ರಕ್ಕೆ ಸಾರ್ವಜನಿಕ ವಿಳಾಸವೂ ಇದ್ದಾಗ ಹೆಚ್ಚಿನವರು ಉದ್ದೇಶಿಸುವುದಕ್ಕಿಂತ ವಿಶಾಲವಾಗಿದೆ; 10.64.7.15:8443 ಸಹೋದ್ಯೋಗಿ ತಲುಪಬಲ್ಲ ಸ್ಥಳದಲ್ಲಿ ಮಾತ್ರ ಕೇಳುವ ಸಂಕುಚಿತ ಆವೃತ್ತಿ. ಅದೇ ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಯ ಹೆಸರನ್ನೂ ಗಮನಿಸಿ, ಏಕೆಂದರೆ ಹಿಂದಿನ ಪರೀಕ್ಷೆಯಿಂದ ಉಳಿದ ತಪ್ಪಾದ ನಿದರ್ಶನವು ಪೋರ್ಟ್ ತೆರೆದಿರುವಂತೆ ಕಾಣುವ ಮತ್ತು ತಪ್ಪು ವಿಷಯದೊಂದಿಗೆ ಉತ್ತರಿಸುವ ಸಾಮಾನ್ಯ ಕಾರಣ.
ನಂತರ ಆ ವಿಳಾಸಕ್ಕೆ ಏನಾದರೂ ಮಾರ್ಗನಿರ್ದೇಶಿಸಬಹುದೇ ಎಂದು ಕೇಳಿ
ಸುರಂಗದ ವಿಳಾಸವು ಆ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಸುರಂಗಕ್ಕೆ ಕಳುಹಿಸಲು ಸಂರಚಿಸಲಾದ ಸಹವರ್ತಿಗಳಿಗೆ ಮಾತ್ರ ಅರ್ಥಪೂರ್ಣ. ಸಹೋದ್ಯೋಗಿಯ ಯಂತ್ರಕ್ಕೆ ತನ್ನದೇ ಆದ ಕೋಷ್ಟಕವಿದೆ, ಮತ್ತು ಸುರಂಗದ ಉಪಜಾಲಕ್ಕೆ ಮಾರ್ಗವಿಲ್ಲದಿದ್ದರೆ, ಪ್ಯಾಕೆಟ್ ಡೀಫಾಲ್ಟ್ ಗೇಟ್‌ವೇಗೆ ಹೋಗಿ ವಿಳಾಸವು ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂದು ತಿಳಿಯದ ಸ್ಥಳದಲ್ಲಿ ಸಾಯುತ್ತದೆ. ಇದು ಕರೆ ಮಾಡುವವರ ಬದಿಯ ಮಾರ್ಗನಿರ್ದೇಶನ ಪ್ರಶ್ನೆ, ನಿಮ್ಮ ಬದಿಯ ಅನುಮತಿ ಅಲ್ಲ.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
ಎರಡು ಕ್ಲೈಂಟ್‌ಗಳ ನಡುವಿನ ಸರ್ವರ್ ಕೂಡ ಅಷ್ಟೇ ಮುಖ್ಯ. ಸಾಮಾನ್ಯ ದೂರ ಪ್ರವೇಶ ವಿನ್ಯಾಸದಲ್ಲಿ ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಗೇಟ್‌ವೇಗೆ ಹೊರಹೋಗುವ ಸಂಪರ್ಕವನ್ನು ತೆರೆಯುತ್ತದೆ ಮತ್ತು ಗೇಟ್‌ವೇ ಆ ಹರಿವುಗಳ ಸ್ಥಿತಿಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಉತ್ತರಗಳು ಈಗಾಗಲೇ ತಿಳಿದಿರುವ ಮಾರ್ಗದಲ್ಲಿ ಹಿಂತಿರುಗುತ್ತವೆ. ಒಂದು ಕ್ಲೈಂಟ್‌ನಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಸಂಪರ್ಕವು ಗೇಟ್‌ವೇ ಸ್ವೀಕರಿಸಿ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಬೇಕಾದ ಹೊಸ ಹರಿವು, ಮತ್ತು ಅನೇಕ ನಿಯೋಜನೆಗಳು ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಪರಸ್ಪರ ಪ್ರತ್ಯೇಕವಾಗಿಡಲು ಅದನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುತ್ತವೆ. ಗ್ರಾಹಕ VPN ಸೇವೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಡೀಫಾಲ್ಟ್ ಆಗಿ ಪ್ರತ್ಯೇಕಿಸುತ್ತವೆ; ಕಾರ್ಪೊರೇಟ್ ಗೇಟ್‌ವೇಗಳು ಕೆಲವೊಮ್ಮೆ ಗುಂಪಿನ ಪ್ರಕಾರ ಅನುಮತಿಸುತ್ತವೆ.
ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ದಿಕ್ಕನ್ನು ಪರಿಶೀಲಿಸಿ. ಸುರಂಗದ ವಿಳಾಸವು ಗೇಟ್‌ವೇಯಿಂದಲೇ ಉತ್ತರಿಸಿ ಸಹವರ್ತಿಯಿಂದ ಉತ್ತರಿಸದಿದ್ದರೆ, ವ್ಯತ್ಯಾಸ ಗೇಟ್‌ವೇಯ ಕ್ಲೈಂಟ್-ಗಳಿಂದ-ಕ್ಲೈಂಟ್ ಸೆಟ್ಟಿಂಗ್, ಮತ್ತು ಸ್ಥಳೀಯ ಫೈರ್‌ವಾಲ್ ಸಂಪಾದನೆಯ ಯಾವುದೇ ಪ್ರಮಾಣವೂ ಅದನ್ನು ಬದಲಿಸಲಾರದು.
ಕೊನೆಯದಾಗಿ, ಹರಿವನ್ನು ಅನುಮತಿಸುವ ನೀತಿಯನ್ನು ಹುಡುಕಿ
ಮಾರ್ಗನಿರ್ದೇಶಿತ ಪ್ಯಾಕೆಟ್ ಮತ್ತು ಉತ್ತರಿಸುವ ಸೇವೆಯ ನಡುವೆ ಮೂರು ನೀತಿ ಪದರಗಳಿವೆ: VPN ಸರ್ವರ್‌ನ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ನಿರ್ಧಾರ, ಹೋಸ್ಟ್ ಫೈರ್‌ವಾಲ್, ಮತ್ತು ನಿದರ್ಶನದ ಮುಂದಿರುವ ಯಾವುದೇ ಕ್ಲೌಡ್ ಭದ್ರತಾ ಗುಂಪು. ಮೂರೂ ಒಪ್ಪಬೇಕು, ಮತ್ತು ಅವು ಬೇರೆ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ, ಆದ್ದರಿಂದ ಮೇಲಿನ ಕೋಷ್ಟಕದ ಲಕ್ಷಣವು ಬ್ರೌಸರ್‌ನ ದೋಷ ಸಂದೇಶಕ್ಕಿಂತ ಹೆಚ್ಚು ಉಪಯುಕ್ತ.
ಯಶಸ್ವಿ ಬೈಂಡ್ ನಂತರ ಜನರು ಮರೆಯುವ ಪದರ ಹೋಸ್ಟ್ ಫೈರ್‌ವಾಲ್, ಏಕೆಂದರೆ LAN ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಪೋರ್ಟ್ ಅನ್ನು ಅನುಮತಿಸುವ ನಿಯಮವು ಸುರಂಗದ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಅದನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅನುಮತಿಸುವುದಿಲ್ಲ. ಇಂಟರ್ಫೇಸ್‌ಗೆ ಸೀಮಿತವಾದ ನಿಯಮಗಳು ಸರಿಯಾದ ವಿನ್ಯಾಸ ಮತ್ತು ಕಚೇರಿಯಿಂದ ಕೆಲಸ ಮಾಡಿ ಮನೆಯಿಂದ ಕೆಲಸ ಮಾಡದ ಸೇವೆಯ ಸಾಮಾನ್ಯ ಕಾರಣವೂ ಹೌದು. ನಿಯಮದ ಪೋರ್ಟ್ ಸಂಖ್ಯೆಯಲ್ಲ, ಅದರ ವ್ಯಾಪ್ತಿಯನ್ನು ಓದಿ.
ಸ್ಥಿತಿ ಆಧಾರಿತ ಫಿಲ್ಟರಿಂಗ್ ವಿರುದ್ಧ ಪ್ರಕರಣವನ್ನು ವಿವರಿಸುತ್ತದೆ. ನಿಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಿಂದ ಹೊರಹೋಗುವ ಸಂಪರ್ಕವು ಸ್ಥಿತಿಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ, ಮತ್ತು ಅದಕ್ಕೆ ಉತ್ತರಗಳು ಒಳಬರುವ ನಿಯಮವಿಲ್ಲದೆ ಅನುಮತಿಸಲ್ಪಡುತ್ತವೆ. ಸಹೋದ್ಯೋಗಿಯ ಸಂಪರ್ಕವು ಹಿಂದೆ ಸ್ಥಿತಿಯಿಲ್ಲದ ಸಂಪೂರ್ಣ ಹೊಸ ಹರಿವು, ಆದ್ದರಿಂದ ಅದಕ್ಕೆ ಸ್ಪಷ್ಟ ಅನುಮತಿ ಬೇಕು. ಈ ಅಸಮಾನತೆಯೇ ನಿಮ್ಮ ಸ್ವಂತ ಯಂತ್ರದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಬ್ರೌಸರ್ ಅಧಿವೇಶನವು ಸೇವೆಯು ಹೊರಗಿನಿಂದ ತಲುಪಬಲ್ಲದೇ ಎಂಬ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳದಿರುವ ಸಂಪೂರ್ಣ ಕಾರಣ.
ಒಂದು ಪರಿಶೀಲನೆ ವಿಫಲವಾದಾಗ ಸುರಂಗವಲ್ಲ, ವಿನ್ಯಾಸವನ್ನು ಬದಲಿಸಿ
ಸಹೋದ್ಯೋಗಿ ನಿಮ್ಮ ಸ್ಥಳೀಯ ಸೇವೆಯನ್ನು ತೆರೆಯಬೇಕು ಎಂಬುದು ಅಗತ್ಯವಾದರೆ, ಪ್ರಾಮಾಣಿಕ ಉತ್ತರ ಸಾಮಾನ್ಯವಾಗಿ ಒಳಬರುವ ಪ್ರವೇಶಕ್ಕಾಗಿ ನಿರ್ಮಿಸಿದ ಕಾರ್ಯವ್ಯವಸ್ಥೆ. ಹಿಮ್ಮುಖ SSH ಸುರಂಗ ಅತಿ ಚಿಕ್ಕದು: ನಿಮ್ಮ ಯಂತ್ರವು ಸಹೋದ್ಯೋಗಿ ಈಗಾಗಲೇ ತಲುಪಬಲ್ಲ ಹೋಸ್ಟ್‌ಗೆ ಹೊರಹೋಗಿ ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಮತ್ತು ಶ್ರೋತೃವು ಆ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ.
ssh -N -R 8443:127.0.0.1:8443 [email protected]ರಿಲೇಗೆ ತನ್ನ SSH ಸರ್ವರ್ ಸಂರಚನೆಯಲ್ಲಿ GatewayPorts clientspecified ಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಿದ ಶ್ರೋತೃವು ರಿಲೇಯಲ್ಲಿ loopback ಗೆ ಬೈಂಡ್ ಆಗುತ್ತದೆ ಮತ್ತು ಸಹೋದ್ಯೋಗಿ ಮೊದಲಿನಂತೆಯೇ ಅದೇ ನಿರಾಕರಣೆಯನ್ನು ಎದುರಿಸುತ್ತಾರೆ. ಒಂದು ಮಧ್ಯಾಹ್ನಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಾಲ ಉಳಿಯುವ ಯಾವುದಕ್ಕೂ, ಆರೋಗ್ಯ ಪರಿಶೀಲನೆ ಮತ್ತು ಪ್ರಕಟಿತ ಹೆಸರಿಗೆ ಪ್ರಮಾಣಪತ್ರವಿರುವ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅಥವಾ ingress ಉತ್ತಮ ಸಾಧನ, ಮತ್ತು ಎರಡು ಜಾಲಗಳು ನಿಜವಾಗಿಯೂ ಮಾತನಾಡಬೇಕಾದಾಗ ಎರಡೂ ಉಪಜಾಲಗಳಿಗೆ ಮಾರ್ಗಗಳಿರುವ ಸೈಟ್-ಟು-ಸೈಟ್ ಸುರಂಗ ಸರಿಯಾದ ಉತ್ತರ.
ಈ ವಿನ್ಯಾಸಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಒಡ್ಡುವಿಕೆಯನ್ನು ಸ್ಪಷ್ಟಗೊಳಿಸುತ್ತದೆ, ಮತ್ತು ಅದೇ ಮುಖ್ಯ ಅಂಶ. VPN ನೀವು ಈಗಾಗಲೇ ಬಳಸಲು ಅಧಿಕಾರ ಹೊಂದಿದ್ದ ಜಾಲಗಳ ನಡುವೆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ; ಅದು ಸೇವೆಯನ್ನು ಪ್ರಕಟಿಸುವುದಿಲ್ಲ ಮತ್ತು ಲ್ಯಾಪ್‌ಟಾಪ್ ಅನ್ನು ಇಂಟರ್ನೆಟ್‌ನತ್ತ ಮುಖ ಮಾಡಿದ ಹೋಸ್ಟ್ ಆಗಿ ಪರಿವರ್ತಿಸುವುದಿಲ್ಲ. ಮೂರು ಪದರಗಳಲ್ಲಿ ಯಾವುದನ್ನು ಬದಲಿಸಬೇಕೆಂದು ನಿರ್ಧರಿಸುವುದೇ ಕೆಲಸ, ಮತ್ತು ಸುರಂಗ ಅವುಗಳಲ್ಲಿ ವಿರಳವಾಗಿ ಒಂದಾಗಿರುತ್ತದೆ.