VPN ਹੋਸਟਨਾਮ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ, IP ਪਤੇ ਕੰਮ ਕਰਦੇ ਹਨ: ਕਿੱਥੇ ਵੇਖਣਾ ਹੈ

ਤੁਸੀਂ ਪਤੇ ਰਾਹੀਂ ਸਾਂਝ ਖੋਲ੍ਹ ਸਕਦੇ ਹੋ ਅਤੇ ਉਹੀ ਸਾਂਝ ਨਾਮ ਰਾਹੀਂ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਦਾ ਅਰਥ ਹੈ ਕਿ ਸੁਰੰਗ ਪੈਕਟ ਲੈ ਜਾ ਰਹੀ ਹੈ ਅਤੇ ਨਾਮ ਦੀ ਪਰਤ ਨਹੀਂ। ਇਹ ਇੱਕ ਨਿਰੀਖਣ ਫਾਇਰਵਾਲ ਅਤੇ ਰੂਟ ਬਦਲਣ ਦੇ ਘੁੰਮਣ-ਫਿਰਨ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ। ਨਾਮਾਂ ਨੂੰ ਪਿਛੇਤਰ, ਰਿਜ਼ੌਲਵਰ ਅਤੇ ਸਵਾਲ ਲਈ ਰਾਹ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ VPN ਕਲਾਇੰਟ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਲਾਏ ਬਿਨਾਂ ਰੂਟ ਲਾ ਸਕਦਾ ਹੈ। ਹੇਠਲੀਆਂ ਚਾਰ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ ਅਤੇ ਪਹਿਲੀ ਟੁੱਟਣ ਵਾਲੀ ਉੱਤੇ ਰੁਕੋ।

ਨਾਮ ਉਹ ਸਵਾਲ ਪੁੱਛਦਾ ਹੈ ਜੋ ਪਤਾ ਨਹੀਂ ਪੁੱਛਦਾ

ਪਤਾ ਇੱਕ ਮੰਜ਼ਿਲ ਹੈ ਜਿਸਨੂੰ ਸਟੈਕ ਤੁਰੰਤ ਵਰਤ ਸਕਦਾ ਹੈ। ਛੋਟਾ ਨਾਮ ਇੱਕ ਸਵਾਲ ਹੈ ਜਿਸਨੂੰ ਪਿਛੇਤਰ ਨਾਲ ਵਧਾਉਣਾ, ਰਿਜ਼ੌਲਵਰ ਕੋਲ ਭੇਜਣਾ ਅਤੇ ਜ਼ੋਨ ਜਾਣਨ ਵਾਲੀ ਕਿਸੇ ਚੀਜ਼ ਰਾਹੀਂ ਜਵਾਬ ਦਿਵਾਉਣਾ ਪੈਂਦਾ ਹੈ। ਜੋ ਸੁਰੰਗ ਰੂਟ ਲਾਉਂਦੀ ਹੈ ਪਰ ਰਿਜ਼ੌਲਵਰ ਨਹੀਂ, ਉਹ ਪਹਿਲੇ ਨੂੰ ਚੱਲਦਾ ਅਤੇ ਦੂਜੇ ਨੂੰ ਟੁੱਟਿਆ ਛੱਡਦੀ ਹੈ। ਇਸੇ ਲਈ ਬਹੁਤ ਵੱਖਰੇ VPN ਉਤਪਾਦਾਂ ਵਿੱਚ ਲੱਛਣ ਇੰਨੇ ਇਕਸਾਰ ਦਿਸਦੇ ਹਨ।

ਪਤੇ ਤੋਂ ਬਾਹਰ ਵੱਲ ਕੰਮ ਕਰੋ: ਪਹਿਲਾਂ ਪੂਰਾ ਨਾਮ, ਫਿਰ ਨੰਗਾ ਹੋਸਟਨਾਮ, ਅਤੇ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਚੱਲਦਾ ਹੈ ਲਿਖੋ। ਨਮੂਨਾ ਦੱਸਦਾ ਹੈ ਕਿ ਇੱਕ ਵੀ ਸੰਰਚਨਾ ਸਕਰੀਨ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿਹੜੀ ਪਰਤ ਵੇਖਣੀ ਹੈ। FQDN ਹੱਲ ਹੋ ਰਹੇ ਹੋਣ ਸਮੇਂ ਰੂਟਾਂ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣਾ ਵਿਅਰਥ ਮਿਹਨਤ ਹੈ।

ਸੁਰੰਗ ਨੇ ਅਸਲ ਵਿੱਚ ਜੋ ਰਿਜ਼ੌਲਵਰ ਲਾਇਆ ਉਹ ਪੜ੍ਹੋ

ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨੂੰ ਪੁੱਛੋ ਅੰਦਰੂਨੀ ਜ਼ੋਨ ਦੇ ਸਵਾਲ ਕਿਹੜਾ ਰਿਜ਼ੌਲਵਰ ਸੰਭਾਲਦਾ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ VPN ਕਲਾਇੰਟ ਦਾ ਇੰਟਰਫੇਸ ਕਿਹੜੇ ਦਾ ਇਸ਼ਤਿਹਾਰ ਦਿੰਦਾ ਹੈ। ਜੋ ਸਰਵਰ ਅੰਦਰੂਨੀ ਜ਼ੋਨ ਤੋਂ ਬਿਨਾਂ ਜਨਤਕ ਰਿਜ਼ੌਲਵਰ ਥੋਪਦਾ ਹੈ ਉਹ ਠੀਕ ਇਹੀ ਫੇਲ੍ਹ ਹੋਣਾ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਰੂਟਿੰਗ ਖਰਾਬੀ ਨਹੀਂ ਸਗੋਂ ਸੰਰਚਨਾ ਗਲਤੀ ਹੈ।

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

ਡੋਮੇਨ ਨਾਲ ਜੁੜੇ Windows ਕਲਾਇੰਟ ਉੱਤੇ ਨਾਮ-ਥਾਂ ਦੀ ਰੂਟਿੰਗ ਨੀਤੀ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਕਿਹੜਾ ਸਵਾਲ ਕਿਹੜੇ ਰਿਜ਼ੌਲਵਰ ਕੋਲ ਜਾਵੇਗਾ, ਅਤੇ VPN ਅਡੈਪਟਰ ਦੀਆਂ ਆਪਣੀਆਂ DNS ਸੈਟਿੰਗਾਂ ਅਡੈਪਟਰ ਵੇਰਵਿਆਂ ਵਿੱਚ ਦਿਸਦੀਆਂ ਹਨ। ਪਰੋਫਾਈਲ ਨਹੀਂ, ਲਾਗੂ ਨੀਤੀ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਕੈਸ਼ ਵਿੱਚ ਰੱਖੀ ਨੀਤੀ ਉਸਨੂੰ ਲਾਉਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਤੋਂ ਵੱਧ ਜੀ ਸਕਦੀ ਹੈ। ਜੇ ਰਿਜ਼ੌਲਵਰ ਪੂਰੇ ਨਾਮ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ ਛੋਟੇ ਨਾਮ ਦਾ ਨਹੀਂ, ਤਾਂ ਸਮੱਸਿਆ ਪਹਿਲਾਂ ਹੀ ਪਿਛੇਤਰਾਂ ਦੀ ਸੂਚੀ ਵਿੱਚ ਚਲੀ ਗਈ ਹੈ।

Get-DnsClientNrptPolicy
ipconfig /all

ਜੇ ਅੰਦਰੂਨੀ ਜ਼ੋਨ ਸਹੀ ਸਰਵਰ ਰਾਹੀਂ ਹੱਲ ਹੁੰਦਾ ਹੈ ਤਾਂ ਰੁਕੋ। ਰਿਜ਼ੌਲਵਰ ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ।

ਪਿਛੇਤਰ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲੇ ਛੋਟੇ ਨਾਮ ਸਮਝਾਉਂਦੇ ਹਨ

ਇੱਕ ਲੇਬਲ ਵਾਲਾ ਨਾਮ ਸਵਾਲ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਕਨੈਕਸ਼ਨ ਦੀ ਪਿਛੇਤਰ ਸੂਚੀ ਨਾਲ ਵਧਾਇਆ ਜਾਂਦਾ ਹੈ। ਜੇ VPN ਅੰਦਰੂਨੀ ਪਿਛੇਤਰ ਨਹੀਂ ਪਹੁੰਚਾਉਂਦਾ, ਤਾਂ fileserver ਕਦੇ ਵੀ fileserver.corp.example ਨਹੀਂ ਬਣਦਾ, ਅਤੇ ਸਵਾਲ ਅਜਿਹੇ ਨਾਮ ਵਜੋਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ ਜਿਸਨੂੰ ਕੋਈ ਜਨਤਕ ਰਿਜ਼ੌਲਵਰ ਨਹੀਂ ਜਾਣਦਾ। ਪਿਛੇਤਰ ਥੋਪਣਾ, ਜਾਂ ਪੂਰਾ ਨਾਮ ਟਾਈਪ ਕਰਨਾ, ਸਰਵਰ ਉੱਤੇ ਕੁਝ ਬਦਲੇ ਬਿਨਾਂ ਧਾਰਨਾ ਜਾਂਚਦਾ ਹੈ।

nslookup fileserver.corp.example
ping -a 192.168.50.20

Linux ਵਿੱਚ ਰਿਜ਼ੌਲਵਰ ਸੇਵਾ DNS ਸਰਵਰ ਨੂੰ ਇੱਕ ਲਿੰਕ ਅਤੇ ਰੂਟਿੰਗ ਡੋਮੇਨਾਂ ਦੇ ਸਮੂਹ ਨਾਲ ਬੰਨ੍ਹਦੀ ਹੈ, ਇਸ ਲਈ ਸੁਰੰਗ ਦੇ ਲਿੰਕ ਨਾਲ ਜੁੜਿਆ ਨਾ ਹੋਣ ਵਾਲਾ ਥੋਪਿਆ ਸਰਵਰ ਉਵੇਂ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਉਹ ਉੱਥੇ ਹੀ ਨਾ ਹੋਵੇ। ਸਿਰਫ਼ ਸਥਾਨਕ ਰਿਜ਼ੌਲਵਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਸਕਣ ਵਾਲੀ stub ਫਾਈਲ ਨਹੀਂ, ਲਿੰਕ ਅਨੁਸਾਰ ਸਥਿਤੀ ਵੇਖੋ। ਉਹੀ ਵੰਡ ਉਲਟੀ ਦਿਸ਼ਾ ਵਿੱਚ ਵੀ ਦਿਸਦੀ ਹੈ: ਮੌਜੂਦ ਪਰ ਸੁਰੰਗ ਇੰਟਰਫੇਸ ਉੱਤੇ ਲਾਗੂ ਨਾ ਕੀਤਾ ਖੋਜ ਡੋਮੇਨ ਬੇਤਰਤੀਬ ਦਿਸਣ ਵਾਲੀਆਂ ਛੋਟੇ-ਨਾਮ ਫੇਲ੍ਹਤਾਵਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ।

ਜੇ ਪਿਛੇਤਰ ਜੋੜਨ ਨਾਲ ਇਹ ਠੀਕ ਹੋ ਜਾਵੇ, ਤਾਂ ਬਾਕੀ ਕੰਮ ਹਰ ਵਰਤੋਂਕਾਰ ਨੂੰ ਇਸਨੂੰ ਟਾਈਪ ਕਰਨ ਲਈ ਕਹਿਣ ਦੀ ਥਾਂ ਉਹ ਪਿਛੇਤਰ VPN ਪਰੋਫਾਈਲ ਰਾਹੀਂ ਪਹੁੰਚਾਉਣਾ ਹੈ।

NetBIOS ਅਤੇ WINS ਵੱਖਰੀ ਕਾਰਵਿਧੀ ਹਨ

ਪੁਰਾਣਾ SMB ਅਜੇ ਵੀ ਨੰਗਾ ਨਾਮ NetBIOS ਨਾਮ ਸੇਵਾ ਨਾਲ ਲੱਭ ਸਕਦਾ ਹੈ, ਜੋ ਪ੍ਰਸਾਰਣ ਰਾਹੀਂ ਜਾਂ WINS ਸਰਵਰ ਰਾਹੀਂ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। ਪ੍ਰਸਾਰਣ ਇੱਕ ਪ੍ਰਸਾਰਣ ਡੋਮੇਨ ਦੇ ਅੰਦਰ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਪਹਿਲੇ ਰਾਊਟਰ ਉੱਤੇ ਰੁਕ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਸੁਰੰਗ ਦੇ ਪਾਰ ਨਹੀਂ ਜਾ ਸਕਦਾ; WINS ਚੱਲਦਾ ਹੈ ਕਿਉਂਕਿ ਕਲਾਇੰਟ ਕੋਲ ਰਜਿਸਟਰ ਕਰਨ ਅਤੇ ਪੁੱਛਣ ਲਈ ਇੱਕ ਯੂਨੀਕਾਸਟ ਪਤਾ ਹੁੰਦਾ ਹੈ। ਇਸੇ ਲਈ ਸਿਰਫ਼ IP ਲੈ ਜਾਣ ਵਾਲਾ VPN ਵੀ WINS ਸੰਰਚਿਤ ਅਤੇ ਪਹੁੰਚਯੋਗ ਹੋਣ ਸਮੇਂ ਪੁਰਾਣੇ ਨਾਮ ਸਮਰਥਨ ਕਰ ਸਕਦਾ ਹੈ।

nbtstat -n
nbtstat -R

ਆਧੁਨਿਕ SMB ਲਈ DNS ਅਤੇ ਪੂਰੇ ਨਾਮ ਉੱਤੇ ਭਰੋਸਾ ਕਰੋ, ਅਤੇ ਪੁਰਾਣਾ ਰਾਹ ਰਿਟਾਇਰ ਕਰੋ। ਜੇ ਇਹ ਸੱਚਮੁੱਚ ਪੁਰਾਣਾ ਹੈ, ਤਾਂ WINS ਦਿਓ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਬਦਲੋ; ਵਿਚਕਾਰਲਾ ਰਾਹ ਇੱਕ ਸਹਾਇਤਾ ਕਤਾਰ ਹੈ ਜੋ ਕਦੇ ਖਾਲੀ ਨਹੀਂ ਹੁੰਦੀ।

ਇਹ ਸਫ਼ਰ ਤਦ ਮੁੱਕਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਦੱਸ ਸਕੋ ਕਿ ਕਿਹੜੀ ਪਰਤ ਫੇਲ੍ਹ ਹੋਈ: ਰਿਜ਼ੌਲਵਰ, ਪਿਛੇਤਰ ਜਾਂ ਪੁਰਾਣੀ ਖੋਜ। ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਰਿਜ਼ੌਲਵਰ ਅਤੇ ਚੱਲਿਆ ਨਾਮ-ਰੂਪ ਲਿਖੋ, ਕਿਉਂਕਿ ਅਗਲਾ ਬੰਦਾ ਉਸੇ ਲੱਛਣ ਤੋਂ ਸ਼ੁਰੂ ਕਰੇਗਾ।