VPN ಸಂಪರ್ಕದಲ್ಲಿರುವಾಗ ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ ತಲುಪಲಾಗದಿದ್ದರೆ? ನಾಲ್ಕು ಪರಿಶೀಲನೆಗಳು

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

ಮೊದಲು, ಕ್ಲೈಂಟ್ ಸ್ಥಾಪಿಸಿದ ಮಾರ್ಗ ಕೋಷ್ಟಕವನ್ನು ನೋಡಿ

VPN ಸಂಪರ್ಕದಲ್ಲಿರುವಾಗ ಕ್ಲೈಂಟ್ನ ಮಾರ್ಗ ಕೋಷ್ಟಕವನ್ನು ತೆರೆಯಿರಿ. Linux ನಲ್ಲಿ ip route, Windows ನಲ್ಲಿ route print ಅಥವಾ Get-NetRoute, ಮತ್ತು macOS ನಲ್ಲಿ netstat -rn ಬಳಸಿ. ನೀವು ಟನೆಲ್ ಮೂಲಕ ಹೋಗುವ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಮತ್ತು ಭೌತಿಕ ಡೀಫಾಲ್ಟ್ಗೆ ಏನಾಯಿತು ಎಂಬುದನ್ನು ಹುಡುಕುತ್ತಿದ್ದೀರಿ.

ಪೂರ್ಣ ಟನೆಲ್ ಕ್ಲೈಂಟ್ 0.0.0.0/0 ಅನ್ನು ಬದಲಿಸುವ ಬದಲು ಸಾಮಾನ್ಯವಾಗಿ ಎರಡು ಅರ್ಧ-ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ: 0.0.0.0/1 ಮತ್ತು 128.0.0.0/1. ಮೂಲ ಡೀಫಾಲ್ಟ್ ಕಾಣಿಸುತ್ತಲೇ ಇರುತ್ತದೆ ಆದರೆ ಪ್ರತಿ ಹುಡುಕಾಟದಲ್ಲೂ ಸೋಲುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೋಷ್ಟಕ ಸಂಪೂರ್ಣವಾಗಿ ಕಾಣಿಸಬಹುದು ಆದರೆ ಉಪಜಾಲದ ಹೊರಗಿನ ಎಲ್ಲ ಸಂಚಾರ ಚಲಿಸುತ್ತದೆ. VPN ಕ್ಲೈಂಟ್ ಸ್ಪ್ಲಿಟ್ ಟನೆಲ್ ಆಯ್ಕೆಯನ್ನು ನೀಡಿ ನೀತಿ ಅನುಮತಿಸಿದರೆ, ಅದೇ ಅತ್ಯಂತ ಸ್ವಚ್ಛ ಪರಿಹಾರ.

ಟನೆಲ್ ಡೀಫಾಲ್ಟ್ ಆಗಿಯೇ ಉಳಿಯಬೇಕಾದರೆ, ಬದಲಿಗೆ ಸ್ಥಳೀಯ ಉಪಜಾಲವನ್ನು ಪಿನ್ ಮಾಡಿ. Linux ನಲ್ಲಿ ಮಾರ್ಗವು ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಗೇಟ್ವೇಯನ್ನು ಹೆಸರಿಸುತ್ತದೆ; Windows ನಲ್ಲಿ -p ಸೇರಿಸಿ ಅದನ್ನು ಶಾಶ್ವತಗೊಳಿಸಿ ಮತ್ತು ಇಂಟರ್ಫೇಸ್ ಸಂಖ್ಯೆಯನ್ನು ಊಹಿಸದೆ route print ನಿಂದ ಓದಿ:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

ಪಿನ್ ಮಾಡಿದ ಮಾರ್ಗವು ಅದು ಹೆಸರಿಸುವ ವಿಳಾಸ ಅದೇ ಆಗಿರುವವರೆಗೆ ಮಾತ್ರ ನಿಲ್ಲುತ್ತದೆ. ಪ್ರತಿ ಸಂಪರ್ಕದಲ್ಲೂ Wi-Fi ಅಡಾಪ್ಟರ್ಗೆ ಹೊಸ ಸಂಖ್ಯೆ ಬರುವ ಲ್ಯಾಪ್ಟಾಪ್ ಮತ್ತೆ ನಿಯಮ ಮುರಿಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಸರಿಪಡಿಸುವಿಕೆ ವಿಫಲವಾಯಿತು ಎಂದು ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ಇಂಟರ್ಫೇಸ್ ವಿಳಾಸವನ್ನು ಪರಿಶೀಲಿಸಿ.

ಎರಡನೆಯದಾಗಿ, ಆ ವಿಳಾಸ ಮೊದಲಿನಿಂದಲೂ ಸ್ಥಳೀಯವಾಗಿತ್ತೆ ಎಂದು ಖಚಿತಪಡಿಸಿ

ಗಮ್ಯಸ್ಥಾನವು ಸಂಪರ್ಕಿತ ಉಪಜಾಲದ ಒಳಗಿದ್ದರೆ, ಟನೆಲ್ನ ಡೀಫಾಲ್ಟ್ ಎಂದಿಗೂ ಅನ್ವಯಿಸುವುದಿಲ್ಲ ಮತ್ತು VPN ಕಾರಣವಲ್ಲ. 192.168.1.0/24 ಇರುವ ಕ್ಲೈಂಟ್ನಲ್ಲಿ 192.168.1.40 ನಲ್ಲಿರುವ ಮುದ್ರಕ ಸಂಪರ್ಕಿತ ಮಾರ್ಗವನ್ನು ಬಳಸುತ್ತದೆ; ಆ ವಿಳಾಸ ವಿಫಲವಾದರೆ, VPN ಬದಲು ಸಾಧನ, ಸ್ವಿಚ್ ಅಥವಾ ಕ್ಲೈಂಟ್ನ ಫೈರ್ವಾಲ್ ಅನ್ನು ನೋಡಿ.

ಜನರನ್ನು ದಾರಿತಪ್ಪಿಸುವ ಸಂದರ್ಭ ಸ್ಥಳೀಯ ಸರ್ವರ್ಗೆ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಇರುವುದು. LAN ಒಳಗಿನಿಂದ ರೂಟರ್ನ WAN ವಿಳಾಸವನ್ನು ತಲುಪಿ ಹಿಂತಿರುಗಿ ಬರಲು ಹೇರ್ಪಿನ್ NAT ಬೇಕು, ಮತ್ತು ಅನೇಕ ರೂಟರ್ಗಳು ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡಿಂಗ್ಗೆ ಅದನ್ನು ಜಾರಿಗೊಳಿಸುವುದೇ ಇಲ್ಲ. ಖಾಸಗಿ ವಿಳಾಸವನ್ನು ಸಾರ್ವಜನಿಕದ ಪಕ್ಕದಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ. ಖಾಸಗಿ ವಿಳಾಸ ಕೆಲಸ ಮಾಡಿ ಸಾರ್ವಜನಿಕವು ಮಾಡದಿದ್ದರೆ, VPN ಮೊದಲೇ ಇದ್ದ NAT ಮಿತಿಯನ್ನು ಬಯಲಿಗೆ ಎಳೆದಷ್ಟೇ.

ಹೋಸ್ಟ್ನಾಮ್ ಇದನ್ನು ಇನ್ನಷ್ಟು ಕೆಡಿಸುತ್ತದೆ. ಸ್ಥಳೀಯ ಹೆಸರು ಈಗ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸಿದರೆ, ಕ್ಲೈಂಟ್ ಹಿಂತಿರುಗಲಾಗದ ಮಾರ್ಗವನ್ನೇ ಪ್ರಯತ್ನಿಸುತ್ತಿರುತ್ತದೆ. ಪರೀಕ್ಷೆಗೆ ಖಾಸಗಿ ವಿಳಾಸ ಬಳಸಿ, ನಂತರ ಇನ್ನೊಂದು ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಸೇರಿಸುವ ಬದಲು ಹೆಸರನ್ನು ಸರಿಪಡಿಸಿ.

ಮೂರನೆಯದಾಗಿ, ಈಗ ಹೆಸರುಗಳಿಗೆ ಯಾರು ಉತ್ತರಿಸುತ್ತಾರೆ ಎಂದು ನೋಡಿ

ಕಾರ್ಪೊರೇಟ್ ರೆಸಾಲ್ವರ್ಗೆ ಇಂಟ್ರಾನೆಟ್ ತಿಳಿದಿದೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ NAS ಹೋಸ್ಟ್ನಾಮ್, ಮುದ್ರಕದ Bonjour ಹೆಸರು ಅಥವಾ ರೂಟರ್ನ ಸ್ಥಳೀಯ ಅಲಿಯಾಸ್ ಬಗ್ಗೆ ಏನೂ ತಿಳಿದಿಲ್ಲ. VPN ತನ್ನ DNS ಸರ್ವರ್ಗಳನ್ನು ತಳ್ಳಿದಾಗ, ಆ ವಿಳಾಸಗಳು ಇನ್ನೂ ತಲುಪಬಹುದಾದರೂ ಆ ಹೆಸರುಗಳು ಪರಿಹಾರವಾಗುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತವೆ. ಹೆಸರನ್ನು ನೇರವಾಗಿ ಪ್ರಶ್ನಿಸಿ ಮತ್ತು ಸಾಧನವು ಹೊಂದಿದೆ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿರುವ ವಿಳಾಸದೊಂದಿಗೆ ಉತ್ತರವನ್ನು ಹೋಲಿಸಿ.

Linux ನಲ್ಲಿ resolvectl query nas.local ಯಾವ ರೆಸಾಲ್ವರ್ ಉತ್ತರಿಸಿತು ಎಂದು ತೋರಿಸುತ್ತದೆ. Windows ನಲ್ಲಿ nslookup nas.local ಸರ್ವರ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ipconfig /all ರೆಸಾಲ್ವರ್ಗಳ ಕ್ರಮವನ್ನು ತೋರಿಸುತ್ತದೆ. ಸ್ಥಳೀಯ ಪ್ರತ್ಯಯವನ್ನು ಈಗ ಕಾರ್ಪೊರೇಟ್ ರೆಸಾಲ್ವರ್ ನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ, ಆ ಪ್ರತ್ಯಯವನ್ನು ಸ್ಥಳೀಯ ರೆಸಾಲ್ವರ್ಗೆ ಹಿಂತಿರುಗಿಸಿ ಅಥವಾ ಸಾಧನಕ್ಕೆ IP ವಿಳಾಸ ಬಳಸಿ.

ಅನ್ವೇಷಣೆ ಬೇರೆ ಪದರ. mDNS ಮತ್ತು ಬ್ರಾಡ್ಕಾಸ್ಟ್ ಮಾರ್ಗಿತ ಟನೆಲ್ ದಾಟುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಸಾಧನ ವಿಳಾಸದಿಂದ ತಲುಪಬಹುದಾಗಿದ್ದರೂ ಅದರ ಹೆಸರು ಅದೃಶ್ಯವಾಗಿರುತ್ತದೆ. ಪ್ರತಿಫಲಕ ಅಥವಾ ಸ್ಥಳೀಯ DNS ನಮೂದು ಅದನ್ನು ಪರಿಹರಿಸುತ್ತದೆ; ಮಾರ್ಗ ಪರಿಹರಿಸುವುದಿಲ್ಲ.

ನಾಲ್ಕನೆಯದಾಗಿ, ಇನ್ನೊಂದು ಯಂತ್ರವೂ VPN ನಲ್ಲಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ

ನೀವು ತಲುಪಲು ಬಯಸುವ ಯಂತ್ರವೂ VPN ಕ್ಲೈಂಟ್ ನಡೆಸುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಸೆಷನ್ ಬಂದು ಅದರ ಉತ್ತರ ಇನ್ನೊಂದು ಟನೆಲ್ ಮೂಲಕ ಹೋಗಬಹುದು. ಅದರಿಂದ ಸಂಪರ್ಕ ಸ್ಥಾಪಿತವಾಗಿ ನಂತರ ನಿಲ್ಲುತ್ತದೆ, ಅಥವಾ RDP ಮತ್ತು SSH ಪ್ರಯತ್ನ ನಿಮ್ಮ ಕಡೆ ದೋಷವಿಲ್ಲದೆ ಸಮಯ ಮೀರಿ ಹೋಗುತ್ತದೆ. ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಅನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಇನ್ನೊಂದು ಹೋಸ್ಟ್ನ ಮಾರ್ಗ ಕೋಷ್ಟಕ ಮತ್ತು ಅದರ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ನೋಡಿ.

ಸೇವೆ ಯಾವ ವಿಳಾಸದಲ್ಲಿ ಕೇಳುತ್ತಿದೆ ಎಂಬುದನ್ನೂ ಪರಿಶೀಲಿಸಿ. ಟನೆಲ್ ವಿಳಾಸಕ್ಕೆ ಮಾತ್ರ ಬದ್ಧವಾದ listener VPN ನಿಂದ ಬರುವ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸಿ LAN ನಿಂದ ಬರುವವನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ, ಮಾರ್ಗನಿರ್ದೇಶನ ಪರಿಪೂರ್ಣವಾಗಿದ್ದರೂ ಸಹ. ಅದು ಸೇವೆಯ ಸಂರಚನೆ, ಜಾಲ ಮಾರ್ಗವಲ್ಲ, ಮತ್ತು VPN ವಿಳಾಸಕ್ಕೆ ಬೀಗ ಹಾಕಿದ ನಿರ್ವಹಣಾ ಇಂಟರ್ಫೇಸ್ಗಳಲ್ಲಿ ಸಾಮಾನ್ಯ.

ಟನೆಲ್ ಅನ್ನು ಅವಲಂಬಿಸದ ನಿರ್ವಹಣಾ ಮಾರ್ಗವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ: ನಿಮ್ಮ ಮೂಲ ಜಾಲವನ್ನು ಹೆಸರಿಸುವ ಸ್ಥಿರ ಮಾರ್ಗ, LAN ಗೆ ಜೋಡಿಸಿದ ಇನ್ನೊಂದು ಇಂಟರ್ಫೇಸ್, ಅಥವಾ ಟನೆಲ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಳಸದ ಕನ್ಸೋಲ್. ಸೆಷನ್ ಬಿದ್ದ ಮೇಲೆ ಆ ಮಾರ್ಗವನ್ನು ವಿನ್ಯಾಸ ಮಾಡುವುದು ಮುಂದಿನ ಸಂಪರ್ಕಕ್ಕೆ ಮೊದಲು ಸೇರಿಸುವುದಕ್ಕಿಂತ ಬಹಳ ಕಷ್ಟ.

ವಿಫಲವಾದ ಪರಿಶೀಲನೆಗೆ ಹೊಂದುವ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಅನ್ವಯಿಸಿ

ಮಾರ್ಗ ಕೋಷ್ಟಕ ಅರ್ಧ-ಡೀಫಾಲ್ಟ್ ಸ್ವಾಧೀನವನ್ನು ತೋರಿಸಿದರೆ, ನೀತಿ ಅನುಮತಿಸಿದಾಗ ಸ್ಪ್ಲಿಟ್ ಟನೆಲ್ ಮತ್ತು ಅನುಮತಿಸದಿದ್ದಾಗ ಪಿನ್ ಮಾಡಿದ ಸ್ಥಳೀಯ ಮಾರ್ಗವನ್ನು ಆರಿಸಿ. ವಿಳಾಸ ಸಾರ್ವಜನಿಕವೆಂದು ತಿಳಿದರೆ, ಪರೀಕ್ಷೆ ಮತ್ತು ಹೆಸರನ್ನು ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ಬದಲಿಸಿ. ರೆಸಾಲ್ವರ್ ಕೈ ಬದಲಿಸಿದರೆ, ಸ್ಥಳೀಯ ಪ್ರತ್ಯಯಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸಿ ಅಥವಾ ವಿಳಾಸ ಬಳಸಿ. ಇನ್ನೊಂದು ಹೋಸ್ಟ್ ಟನೆಲ್ನಲ್ಲಿದ್ದರೆ, ಅದರ ಹಿಂತಿರುಗು ಮಾರ್ಗ ಅಥವಾ listener ಬಂಧನವನ್ನು ಸರಿಪಡಿಸಿ.

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

VPN ಸಂಪರ್ಕದಲ್ಲಿದ್ದಾಗ ಕೆಲಸ ಮಾಡಿದ ಮಾರ್ಗ, ವಿಳಾಸ ಮತ್ತು ರೆಸಾಲ್ವರ್ ಅನ್ನು ಬರೆದಿಟ್ಟುಕೊಳ್ಳಿ. ಮುಂದಿನ ಮರುಸಂಪರ್ಕ ಅವುಗಳಲ್ಲಿ ಕನಿಷ್ಠ ಒಂದನ್ನು ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಟಿಪ್ಪಣಿ ಮುಂದಿನ ಅಡಚಣೆಯನ್ನು ಹೊಸ ತನಿಖೆಯ ಬದಲು ಸಣ್ಣ ಹೋಲಿಕೆಯಾಗಿ ಮಾಡುತ್ತದೆ.