VPN ਜੁੜਿਆ ਹੋਣ ਵੇਲੇ ਲੋਕਲ ਨੈੱਟਵਰਕ ਨਹੀਂ ਪਹੁੰਚਦਾ? ਚਾਰ ਜਾਂਚਾਂ
VPN ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਪ੍ਰਿੰਟਰ, NAS ਜਾਂ ਰਾਊਟਰ ਦਾ ਪੇਜ ਲੁੱਪ ਹੋ ਜਾਵੇ ਤਾਂ ਕਲਾਇੰਟ, ਮੰਜ਼ਿਲ ਅਤੇ ਰਿਜ਼ੌਲਵਰ ਵੇਖੋ। ਚਾਰ ਜਾਂਚਾਂ ਕਾਰਨ ਲੱਭ ਲੈਂਦੀਆਂ ਹਨ।
ਟਨਲ ਉੱਠਦਾ ਹੈ, ਇੰਟਰਾਨੈੱਟ ਦਿਸਦਾ ਹੈ, ਅਤੇ ਪ੍ਰਿੰਟਰ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। 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 ਦੀ ਕੋਸ਼ਿਸ਼ ਤੁਹਾਡੇ ਪਾਸੇ ਬਿਨਾਂ ਗਲਤੀ ਦੇ ਸਮਾਂ ਸੀਮਾ ਪਾਰ ਕਰ ਜਾਂਦੀ ਹੈ। ਆਪਣੇ ਕਲਾਇੰਟ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਦੂਜੇ ਹੋਸਟ ਦੀ ਰੂਟ ਟੇਬਲ ਅਤੇ ਉਸ ਦਾ ਡਿਫ਼ਾਲਟ ਰਾਹ ਵੇਖੋ।
ਇਹ ਵੀ ਵੇਖੋ ਕਿ ਸੇਵਾ ਕਿਹੜੇ ਪਤੇ ਉੱਤੇ ਸੁਣ ਰਹੀ ਹੈ। ਸਿਰਫ਼ ਟਨਲ ਪਤੇ ਨਾਲ ਬੱਝਿਆ ਲਿਸਨਰ VPN ਤੋਂ ਆਉਣ ਵਾਲੀਆਂ ਜੁੜਾਈਆਂ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ LAN ਤੋਂ ਆਉਣ ਵਾਲੀਆਂ ਨੂੰ ਨਾਂਹ ਕਰਦਾ ਹੈ, ਭਾਵੇਂ ਰੂਟਿੰਗ ਬਿਲਕੁਲ ਠੀਕ ਹੋਵੇ। ਇਹ ਸੇਵਾ ਦੀ ਸੰਰਚਨਾ ਹੈ, ਨੈੱਟਵਰਕ ਰਾਹ ਨਹੀਂ, ਅਤੇ ਇਹ ਉਨ੍ਹਾਂ ਪ੍ਰਬੰਧਨ ਇੰਟਰਫ਼ੇਸਾਂ ਉੱਤੇ ਆਮ ਹੈ ਜੋ VPN ਪਤੇ ਉੱਤੇ ਤਾਲਾ ਲਾ ਕੇ ਬੰਦ ਕੀਤੇ ਗਏ ਸਨ।
ਪ੍ਰਬੰਧਨ ਦਾ ਰਾਹ ਰੱਖੋ ਜੋ ਟਨਲ ਉੱਤੇ ਨਿਰਭਰ ਨਾ ਹੋਵੇ: ਤੁਹਾਡੇ ਸਰੋਤ ਨੈੱਟਵਰਕ ਦਾ ਨਾਂ ਲੈਣ ਵਾਲਾ ਸਥਿਰ ਰੂਟ, LAN ਨਾਲ ਜੁੜਿਆ ਦੂਜਾ ਇੰਟਰਫ਼ੇਸ, ਜਾਂ ਟਨਲ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਚਾ ਕੇ ਲੰਘਣ ਵਾਲਾ ਕੰਸੋਲ। ਸੈਸ਼ਨ ਡਿੱਗਣ ਤੋਂ ਬਾਅਦ ਉਹ ਰਾਹ ਘੜਨਾ ਅਗਲੀ ਜੁੜਾਈ ਤੋਂ ਪਹਿਲਾਂ ਜੋੜਨ ਨਾਲੋਂ ਕਿਤੇ ਔਖਾ ਹੈ।
ਫੇਲ੍ਹ ਹੋਈ ਜਾਂਚ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਸੁਧਾਰ ਲਾਗੂ ਕਰੋ
ਜੇ ਰੂਟ ਟੇਬਲ ਨੇ ਅੱਧ-ਡਿਫ਼ਾਲਟ ਕਬਜ਼ਾ ਦਿਖਾਇਆ, ਤਾਂ ਨੀਤੀ ਇਜਾਜ਼ਤ ਦੇਵੇ ਤਾਂ ਸਪਲਿਟ ਟਨਲ ਅਤੇ ਨਾ ਦੇਵੇ ਤਾਂ ਪਿੰਨ ਕੀਤਾ ਲੋਕਲ ਰੂਟ ਚੁਣੋ। ਜੇ ਪਤਾ ਜਨਤਕ ਨਿਕਲਿਆ, ਤਾਂ ਪਰਖ ਅਤੇ ਨਾਂ ਨਿੱਜੀ ਪਤੇ ਉੱਤੇ ਬਦਲੋ। ਜੇ ਰਿਜ਼ੌਲਵਰ ਨੇ ਹੱਥ ਬਦਲਿਆ, ਤਾਂ ਲੋਕਲ ਸਫ਼ਿਕਸ ਤੱਕ ਸੀਮਤ ਰਹੋ ਜਾਂ ਪਤਾ ਵਰਤੋ। ਜੇ ਦੂਜਾ ਹੋਸਟ ਟਨਲ ਵਿੱਚ ਹੈ, ਤਾਂ ਉਸ ਦਾ ਵਾਪਸੀ ਰਾਹ ਜਾਂ ਲਿਸਨਰ ਬਾਈਂਡਿੰਗ ਠੀਕ ਕਰੋ।
ਇੱਕ ਚੀਜ਼ ਬਦਲੋ, ਫਿਰ ਉਹੀ ਜਾਂਚ ਦੁਹਰਾਓ। ਗਲਤ ਸਬਨੈੱਟ ਲਈ ਜੋੜਿਆ ਰੂਟ, ਗਲਤ ਅੱਖਰਾਂ ਵਾਲਾ ਰਿਜ਼ੌਲਵਰ ਸਫ਼ਿਕਸ ਅਤੇ ਨਵਾਂ ਨੰਬਰ ਮਿਲਣ ਵਾਲੇ ਇੰਟਰਫ਼ੇਸ ਉੱਤੇ ਪਿੰਨ ਕੀਤਾ ਰੂਟ, ਸਾਰੇ ਮੂਲ ਖ਼ਰਾਬੀ ਵਰਗੇ ਦਿਸਦੇ ਹਨ। ਸੁਧਾਰ ਅਤੇ ਸੰਜੋਗ ਵਿੱਚ ਫ਼ਰਕ ਦੁਹਰਾਉਣਾ ਪਾਉਂਦਾ ਹੈ।
VPN ਜੁੜਿਆ ਹੋਣ ਵੇਲੇ ਚੱਲਿਆ ਰੂਟ, ਪਤਾ ਅਤੇ ਰਿਜ਼ੌਲਵਰ ਲਿਖ ਲਓ। ਅਗਲੀ ਮੁੜ-ਜੁੜਾਈ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਬਦਲ ਦੇਵੇਗੀ, ਅਤੇ ਇਹ ਨੋਟ ਅਗਲੀ ਰੁਕਾਵਟ ਨੂੰ ਨਵੀਂ ਪੜਤਾਲ ਦੀ ਥਾਂ ਛੋਟੀ ਤੁਲਨਾ ਬਣਾ ਦੇਵੇਗਾ।