VPN ਉੱਤੇ ਅੰਦਰੂਨੀ ਨਾਮ ਫੇਲ ਹੁੰਦੇ ਹਨ ਜਦਕਿ ਜਨਤਕ ਸਾਈਟਾਂ ਠੀਕ ਖੁੱਲ੍ਹਦੀਆਂ ਹਨ

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

ਦੋ ਲੱਛਣ ਜੋ ਇੱਕ ਖਰਾਬੀ ਨਹੀਂ ਹਨ

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

ਜਾਲ ਇਹ ਹੈ ਕਿ ਹਰ ਥਾਂ ਦਫ਼ਤਰ ਦਾ ਰੈਜ਼ੌਲਵਰ ਸ਼ਾਮਲ ਕਰਨਾ ਪਹਿਲੀ ਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ ਅਤੇ ਦੂਜੀ ਨੂੰ ਪੱਕਾ ਕਰਦਾ ਹੈ। ਹਰ ਥਾਂ ਜਨਤਕ ਰੈਜ਼ੌਲਵਰ ਸ਼ਾਮਲ ਕਰਨਾ ਉਲਟਾ ਕਰਦਾ ਹੈ।

ਦੋਵੇਂ ਨਿਰੀਖਣ ਸਮਾਂ-ਛਾਪ ਨਾਲ ਲਿਖੋ, ਫਿਰ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਚਾਰ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ।

ਕਿਹੜਾ ਐਡਾਪਟਰ ਆਪਣੇ ਰੈਜ਼ੌਲਵਰ ਨੂੰ ਸਵਾਲ ਦਿੰਦਾ ਹੈ

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

ਬਾਈਂਡਿੰਗ ਕ੍ਰਮ ਸਿਰਫ਼ ਅੱਧਾ ਹਿੱਸਾ ਹੈ। ਕਲਾਇੰਟ ਨੂੰ ਇਹ ਵੀ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਨਾਮ ਉਸ ਐਡਾਪਟਰ ਦੇ ਹਨ, ਅਤੇ ਇਹ ਕ੍ਰਮ ਦਾ ਨਹੀਂ, ਸਫ਼ਿਕਸ ਦਾ ਸਵਾਲ ਹੈ।

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

ਛੋਟੇ ਨਾਮ ਨੂੰ ਰੂਟ ਤੋਂ ਪਹਿਲਾਂ ਸਫ਼ਿਕਸ ਚਾਹੀਦਾ ਹੈ

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

ਚੱਲ ਰਹੀ ਮਸ਼ੀਨ ਦਾ ਸਫ਼ਿਕਸ DNS ਟੈਬ ਉੱਤੇ VPN ਐਡਾਪਟਰ ਦੀਆਂ IPv4 ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਕਾਪੀ ਕਰੋ, ਫਿਰ ਦੁਬਾਰਾ ਕਨੈਕਟ ਕਰੋ। Linux ਉੱਤੇ ਇਸਦਾ ਬਰਾਬਰ ਸੁਰੰਗ ਲਿੰਕ ਉੱਤੇ ਖੋਜ ਡੋਮੇਨ ਹੈ, ਜਿਸਨੂੰ systemd-resolved ਗਲੋਬਲ ਦੀ ਬਜਾਏ ਹਰ ਲਿੰਕ ਲਈ ਦਿਖਾਉਂਦਾ ਹੈ।

ਦੋਵੇਂ ਸੈਟਿੰਗਾਂ ਆਪਣੇ ਨੋਟਾਂ ਵਿੱਚ ਵੱਖਰੀਆਂ ਰੱਖੋ। ਸਫ਼ਿਕਸ ਬਦਲਦਾ ਹੈ ਕਿ ਕੀ ਪੁੱਛਿਆ ਜਾਂਦਾ ਹੈ; ਰੈਜ਼ੌਲਵਰ ਪਤਾ ਬਦਲਦਾ ਹੈ ਕਿ ਕਿਸਨੂੰ ਪੁੱਛਿਆ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਠੀਕ ਕਰਨਾ ਜਦੋਂ ਦੂਜੀ ਗਲਤ ਹੋਵੇ, ਅਜਿਹਾ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ ਜੋ ਬੇਤਰਤੀਬ ਲੱਗਦਾ ਹੈ।

ਪਹਿਲਾਂ ਰੈਜ਼ੌਲਵਰ ਨੂੰ ਸਿੱਧਾ ਪੁੱਛੋ, ਫਿਰ ਨਾਮ

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

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

ਪਹਿਲਾ ਕਮਾਂਡ ਕਿਸੇ ਖਾਸ ਸਰਵਰ ਤੋਂ ਪੂਰੀ ਯੋਗ ਨਾਮ ਮੰਗਦਾ ਹੈ। ਜੇ ਉਹ ਜਵਾਬ ਦੇਵੇ, ਰੈਜ਼ੌਲਵਰ ਅਤੇ ਉੱਥੇ ਤੱਕ ਦਾ ਰੂਟ ਠੀਕ ਹਨ ਅਤੇ ਖਰਾਬੀ ਚੋਣ ਜਾਂ ਸਫ਼ਿਕਸ ਵਿੱਚ ਹੈ। ਜੇ ਸਮਾਂ ਖਤਮ ਹੋਵੇ, ਪਤਾ ਗਲਤ ਜਾਂ ਅਪਹੁੰਚ ਹੈ ਅਤੇ ਸਮੱਸਿਆ DNS ਨਹੀਂ, ਰਾਊਟਿੰਗ ਹੈ। ਦੂਜਾ ਕਮਾਂਡ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਛੋਟੇ ਨਾਮ ਨਾਲ ਕੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਤੀਜਾ systemd ਹੋਸਟ ਉੱਤੇ ਹਰ ਲਿੰਕ ਦੀ ਰੈਜ਼ੌਲਵਰ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਛਾਪਦਾ ਹੈ।

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

Linux ਉੱਤੇ /etc/resolv.conf ਦੁਬਾਰਾ ਲਿਖਣ ਵਾਲਾ VPN ਕਲਾਇੰਟ ਸਥਾਨਕ ਰੈਜ਼ੌਲਵਰਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਦਲ ਦਿੰਦਾ ਹੈ। vpnc ਉਸਨੂੰ ਰੋਕਣ ਲਈ DNSUpdate no ਦਿੰਦਾ ਹੈ, ਅਤੇ systemd-resolved ਸੂਚੀਬੱਧ ਡੋਮੇਨਾਂ ਨੂੰ ਹੀ ਸੁਰੰਗ ਲਿੰਕ ਨਾਲ ਰੂਟ ਕਰ ਸਕਦਾ ਹੈ। ਦੋਵੇਂ ਤਰੀਕੇ ਜਨਤਕ ਨਾਮ ਸਥਾਨਕ ਰੈਜ਼ੌਲਵਰ ਕੋਲ ਰੱਖਦੇ ਹਨ ਜਦਕਿ ਅੰਦਰੂਨੀ ਨਾਮ ਦਫ਼ਤਰ ਭੇਜਦੇ ਹਨ।

ਲੀਕ ਨਿਯਮ ਹਨ, ਚੈੱਕਬਾਕਸ ਨਹੀਂ

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

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

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

ਉਹ ਆਖਰੀ ਹਿੱਸਾ ਦਿਖਣ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। route-nopull ਨਾਲ OpenVPN ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਪੁਸ਼ ਕੀਤਾ DNS ਵਿਕਲਪ ਰੂਟਾਂ ਨਾਲ ਹੀ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ, ਜਦ ਤੱਕ ਪੁਲ ਫਿਲਟਰ ਨੂੰ ਉਸਨੂੰ ਰੱਖਣ ਲਈ ਚੌੜਾ ਨਾ ਕੀਤਾ ਜਾਵੇ। dhcp-option DNS ਨੂੰ ਅਣਡਿੱਠ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਪਹਿਲਾਂ ਜੋ ਸੀ ਉਹੀ ਵਰਤਦਾ ਰਹੇਗਾ। ਸਰਵਰ ਪਾਸੇ ਦੇ ਕਿਸੇ ਵੀ ਬਦਲਾਅ ਨੂੰ ਪ੍ਰਭਾਵ ਲਈ ਨਵਾਂ ਸੈਸ਼ਨ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਰੈਜ਼ੌਲਵਰ ਸੂਚੀ ਸੁਰੰਗ ਖੁੱਲ੍ਹਦਿਆਂ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਪੁਰਾਣਾ ਸੈਸ਼ਨ ਪੁਰਾਣੀ ਹਾਲਤ ਦਿਖਾਉਂਦਾ ਰਹਿੰਦਾ ਹੈ।

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