ਤੁਹਾਡੀ /etc/hosts ਐਂਟਰੀ VPN ਦੇ DNS ਤੱਕ ਕਿਉਂ ਨਹੀਂ ਪਹੁੰਚਦੀ

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

Hosts ਸਥਾਨਕ ਓਵਰਰਾਈਡ ਹੈ, ਜ਼ੋਨ ਅੱਪਡੇਟ ਨਹੀਂ

ਫਾਈਲ ਨਾਮ-ਸੇਵਾ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵੱਲੋਂ DNS ਸਰਵਰ ਨੂੰ ਪੁੱਛਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂ ਉਸ ਦੀ ਥਾਂ ਵੇਖੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਮੈਪਿੰਗਾਂ ਦੀ ਸੂਚੀ ਹੈ। 10.40.0.20 build.corp.example ਵਰਗੀ ਲਾਈਨ ਉਸੇ ਇੱਕ ਮਸ਼ੀਨ ’ਤੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਸਿੱਟੇ ਬਦਲਦੀ ਹੈ। ਇਹ ਰਿਕਾਰਡ ਨਹੀਂ ਬਣਾਉਂਦੀ, ਸੁਰੰਗ ਵਿੱਚੋਂ ਨਹੀਂ ਲੰਘਦੀ, ਅਤੇ ਸੁਰੰਗ ਜਿਸ DNS ਸਰਵਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ ਉਸਨੂੰ ਇਸਦੇ ਹੋਣ ਦੀ ਕੋਈ ਭਿਣਕ ਨਹੀਂ।

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

ਦੋ ਕਮਾਂਡਾਂ, ਦੋ ਵੱਖਰੇ ਹਿੱਸੇ

ਇਹ ਬਹਿਸ ਰੋਕਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਫ਼ਰਕ ਨੂੰ ਦੋ ਕਮਾਂਡਾਂ ਵਿੱਚ ਦਿਖਣਯੋਗ ਬਣਾਉਣਾ, ਦੋਵੇਂ hosts ਐਂਟਰੀ ਵਾਲੇ ਕਲਾਇੰਟ ’ਤੇ ਚਲਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

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

ਕ੍ਰਮ ਕਨਫਿਗਰ ਕਰਨ ਯੋਗ ਹੈ, ਅਤੇ ਕਿਸੇ ਖਾਸ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਬਾਰੇ ਕੋਈ ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਜਾਂਚਣਾ ਚਾਹੀਦਾ ਹੈ। /etc/nsswitch.conf ਵਿੱਚ hosts: ਲਾਈਨ ਵੇਖੋ; hosts: files dns ਪਹਿਲਾਂ ਫਾਈਲਾਂ ਵੇਖਦਾ ਹੈ। ਸਿਰਫ਼ ਕ੍ਰਮ ਬਦਲਣ ਲਈ ਉਸ ਉਦਾਹਰਨ ਨੂੰ ਕੰਮ ਕਰ ਰਹੇ ਕਨਫਿਗਰੇਸ਼ਨ ’ਤੇ ਨਕਲ ਨਾ ਕਰੋ, ਕਿਉਂਕਿ ਅਸਲ ਸਿਸਟਮ ਅਕਸਰ ਅਜਿਹੇ ਵਾਧੂ ਸਰੋਤ ਅਤੇ ਸ਼ਰਤੀ ਸੇਵਾ ਐਂਟਰੀਆਂ ਸੂਚੀਬੱਧ ਕਰਦੇ ਹਨ ਜੋ ਉਦਾਹਰਨ ਵਿੱਚ ਨਹੀਂ ਹਨ।

systemd-resolved ਪਰਖ ਨੂੰ ਧੁੰਦਲਾ ਕਰਦਾ ਹੈ

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

resolvectl query build.corp.example
resolvectl status

status ਆਉਟਪੁੱਟ ਹਰ ਲਿੰਕ ਲਈ DNS ਸਰਵਰ ਦੱਸਦਾ ਹੈ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ VPN ਲਿੰਕ ਨੂੰ ਰਿਜ਼ੋਲਵਰ ਮਿਲਿਆ ਵੀ ਜਾਂ ਨਹੀਂ। ਉਹ ਸਵਾਲ hosts ਐਂਟਰੀ ਤੋਂ ਵੱਖਰਾ ਹੈ ਅਤੇ ਜਦੋਂ ਨਿੱਜੀ ਨਾਮ ਇੱਕ ਦੀ ਬਜਾਏ ਹਰ ਵਰਤੋਂਕਾਰ ਲਈ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਤਾਂ ਪੁੱਛਣ ਯੋਗ ਸਵਾਲ ਉਹੀ ਹੈ।

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

VPN ਭਰ ਵਿੱਚ ਨਾਮ ਅਸਲ ਵਿੱਚ ਕੀ ਸਾਂਝਾ ਕਰਦਾ ਹੈ

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

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

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

ਰਿਜ਼ੋਲਵ ਹੋਇਆ ਨਾਮ ਰਾਹ ਨਹੀਂ ਹੈ

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

ਇਸ ਲਈ ਜਦੋਂ ਰਿਪੋਰਟ “ਨਾਮ ਰਿਜ਼ੋਲਵ ਹੁੰਦਾ ਹੈ ਪਰ ਸੇਵਾ ਪਹੁੰਚਯੋਗ ਨਹੀਂ” ਹੋਵੇ, ਤਾਂ ਸਿਸਟਮ ਲੁੱਕਅੱਪ ਦੀ VPN DNS ਸਰਵਰ ਨੂੰ ਸਪਸ਼ਟ ਕਵੈਰੀ ਨਾਲ ਤੁਲਨਾ ਕਰੋ, ਫਿਰ ਜੋ ਪਤਾ ਮਿਲਿਆ ਉਸਨੂੰ ਉਸ ਪਤੇ ਨਾਲ ਜਾਂਚੋ ਜੋ ਸੇਵਾ ਅਸਲ ਵਿੱਚ ਵਰਤਦੀ ਹੈ। systemd-resolved ਸੰਦਰਭ ਉਨ੍ਹਾਂ ਸਥਾਨਕ ਸਰੋਤਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇਹ ਵੇਖਦਾ ਹੈ, ਅਤੇ ਉਸ ਤੁਲਨਾ ਲਈ ਲੋੜੀਂਦਾ ਨਕਸ਼ਾ ਇਹੀ ਹੈ।

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