resolv.conf ਤੁਹਾਡਾ VPN DNS ਕਿਉਂ ਦਿਖਾਉਂਦਾ ਹੈ ਪਰ ਖੋਜਾਂ ਇਸਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੀਆਂ ਹਨ

ਲੌਗਾਂ ਵਿੱਚ ਕੁਝ ਵੀ ਗਲਤ ਨਹੀਂ ਦਿਸਦਾ: ਇੰਟਰਫੇਸ ਚਾਲੂ ਹੈ, ਰਿਜ਼ੌਲਵਰ VPN ਦਾ DNS ਸਰਵਰ ਦੱਸਦਾ ਹੈ, ਅਤੇ ਡਿਸਕ ਦੀ ਫਾਈਲ ਉਸਨੂੰ ਸੂਚੀਬੱਧ ਕਰਦੀ ਹੈ। ਫਿਰ ਵੀ ਇੱਕ ਅੰਦਰੂਨੀ ਹੋਸਟਨਾਮ ਸਥਾਨਕ ਰਾਊਟਰ ਰਾਹੀਂ ਹੱਲ ਹੁੰਦਾ ਹੈ। ਇਹ ਤਿੰਨ ਬਿਆਨ ਇੱਕ-ਦੂਜੇ ਦੇ ਵਿਰੋਧੀ ਨਹੀਂ ਹਨ, ਕਿਉਂਕਿ ਫਾਈਲ, ਹਰ ਲਿੰਕ ਦੀ ਸਥਿਤੀ ਅਤੇ ਖੋਜ ਦਾ ਮਾਰਗ ਵੱਖਰੀਆਂ ਵਸਤੂਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਸੰਯੋਗ ਨਾਲ ਇੱਕੋ ਨਾਮ ਹੈ। ਅੱਗੇ systemd-resolved ਵਾਲੇ ਹੋਸਟ 'ਤੇ ਕਿਊਰੀ ਅਸਲ ਵਿੱਚ ਜੋ ਮਾਰਗ ਲੈਂਦੀ ਹੈ ਉਹ ਦਿੱਤਾ ਗਿਆ ਹੈ।

resolv.conf ਨਾਮ ਦੀਆਂ ਤਿੰਨ ਵਸਤੂਆਂ

resolved ਵਾਲੇ ਹੋਸਟ 'ਤੇ /etc/resolv.conf ਆਮ ਤੌਰ 'ਤੇ /run/systemd/resolve/stub-resolv.conf ਵੱਲ ਸਿੰਬੋਲਿਕ ਲਿੰਕ ਹੁੰਦਾ ਹੈ। ਉਸ ਟਾਰਗਿਟ ਵਿੱਚ ਸਥਾਨਕ stub ਸਰੋਤੇ ਦਾ ਪਤਾ, 127.0.0.53, ਅਤੇ resolved ਵੱਲੋਂ ਗਿਣੇ ਖੋਜ ਡੋਮੇਨ ਹੁੰਦੇ ਹਨ। ਇਹ ਸਥਿਤੀ ਦਾ ਦ੍ਰਿਸ਼ ਹੈ, ਸਥਿਤੀ ਆਪ ਨਹੀਂ।

ਸਥਿਤੀ resolved ਦੀ ਹਰ ਲਿੰਕ ਵਾਲੀ ਸੰਰਚਨਾ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ, ਇਸੇ ਲਈ resolvectl status ਫਾਈਲ ਨਾਲ ਅਸਹਿਮਤ ਹੋ ਕੇ ਵੀ ਸਹੀ ਹੋ ਸਕਦਾ ਹੈ। ਹਰ ਲਿੰਕ ਆਪਣੇ ਸਰਵਰ ਅਤੇ ਆਪਣੇ ਰਾਊਟਿੰਗ ਡੋਮੇਨ ਲੈ ਕੇ ਚੱਲਦਾ ਹੈ, ਅਤੇ ਕਿਊਰੀ ਆਉਣ 'ਤੇ stub ਉਸ ਡੇਟਾ ਦੀ ਸਲਾਹ ਲੈਂਦਾ ਹੈ। systemd-resolved ਦਾ ਮੈਨੂਅਲ ਬਣੀਆਂ ਫਾਈਲਾਂ ਅਤੇ ਹਰ ਲਿੰਕ ਦੇ ਮਾਡਲ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ; ਦ੍ਰਿਸ਼ ਅਤੇ ਸਥਿਤੀ ਵਿਚਕਾਰ ਵੰਡ ਯਾਦ ਰੱਖਣ ਯੋਗ ਹਿੱਸਾ ਹੈ। ਸਿੰਬੋਲਿਕ ਲਿੰਕ ਦਾ ਟਾਰਗਿਟ ਬਦਲਣ ਨਾਲ ਰਵਾਇਤੀ ਕਲਾਇੰਟ ਜੋ ਪੜ੍ਹਦੇ ਹਨ ਉਹ ਬਦਲਦਾ ਹੈ, ਰਿਜ਼ੌਲਵਰ ਜੋ ਜਾਣਦਾ ਹੈ ਉਹ ਨਹੀਂ।

ਤੀਜੀ ਵਸਤੂ, /run/systemd/resolve/resolv.conf, ਹਰ ਲਿੰਕ ਨੂੰ ਇੱਕ ਸਰਵਰ ਸੂਚੀ ਵਿੱਚ ਸਮਤਲ ਕਰ ਦਿੰਦੀ ਹੈ। ਉਸ ਫਾਈਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਪ੍ਰੋਗਰਾਮ ਕਿਊਰੀ ਸਿੱਧੀਆਂ ਸੂਚੀਬੱਧ ਸਰਵਰਾਂ ਨੂੰ ਭੇਜਦਾ ਹੈ ਅਤੇ stub ਛੱਡ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਹਰ ਲਿੰਕ ਦੀ ਨੀਤੀ ਹੁਣ ਉਸ 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀ। ਇਸ ਲਈ ਇੱਕੋ ਮਸ਼ੀਨ ਦੇ ਦੋ ਪ੍ਰੋਗਰਾਮ ਇੱਕੋ ਨਾਮ ਦਾ ਵੱਖਰਾ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹਨ, ਅਤੇ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਟੁੱਟਿਆ ਨਹੀਂ।

NSS ਰਾਹੀਂ ਇੱਕ ਖੋਜ ਦਾ ਪਿੱਛਾ ਕਰੋ

glibc ਨਾਮ ਦਾ ਜਵਾਬ ਕੌਣ ਦੇਵੇਗਾ ਇਹ ਤੈਅ ਕਰਨ ਲਈ /etc/nsswitch.conf ਪੜ੍ਹਦਾ ਹੈ। ਜਿਸ hosts ਲਾਈਨ ਵਿੱਚ resolve ਹੈ ਉਹ ਸਵਾਲ nss-resolve ਨੂੰ ਭੇਜਦੀ ਹੈ, ਜੋ D-Bus ਰਾਹੀਂ resolved ਨੂੰ ਪੁੱਛਦਾ ਹੈ ਅਤੇ ਹਰ ਲਿੰਕ ਦਾ ਜਵਾਬ ਲੈਂਦਾ ਹੈ। ਸਿਰਫ਼ files dns ਵਾਲੀ ਲਾਈਨ ਕਿਊਰੀ ਉਸ ਪਤੇ 'ਤੇ ਭੇਜਦੀ ਹੈ ਜੋ /etc/resolv.conf ਕੋਲ ਹੈ।

ਇਹ ਇੱਕੋ ਲਾਈਨ ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ dig ਵਿਚਕਾਰ ਬਹੁਤੇ ਮਤਭੇਦ ਸਮਝਾਉਂਦੀ ਹੈ। dig ਸਿੱਧਾ resolv.conf ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ NSS ਨੂੰ ਕਦੇ ਨਹੀਂ ਛੂਹਦਾ, ਇਸ ਲਈ ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਵੱਲੋਂ ਵਰਤੇ ਮਾਰਗ ਦੀ ਥਾਂ stub ਜਾਂ ਉੱਪਰਲੇ ਸਰਵਰ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। getent hosts internal.example NSS ਰਾਹੀਂ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸਦੇ ਜਵਾਬ ਦੀ dig ਦੇ ਜਵਾਬ ਨਾਲ ਤੁਲਨਾ ਪਹਿਲਾ ਲਾਭਦਾਇਕ ਮਾਪ ਹੈ।

ਆਪਣਾ ਰਿਜ਼ੌਲਵਰ ਨਾਲ ਲਿਆਉਣ ਵਾਲੀਆਂ ਜਾਂ ਨਿਸ਼ਚਿਤ ਐਂਡਪੌਇੰਟ 'ਤੇ HTTPS ਰਾਹੀਂ DNS ਬੋਲਣ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੋਵੇਂ ਮਾਰਗ ਛੱਡ ਦਿੰਦੀਆਂ ਹਨ। resolv.conf ਵਿੱਚ ਜਾਂ resolved ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਕੁਝ ਵੀ ਉਨ੍ਹਾਂ ਨੂੰ ਸੀਮਿਤ ਨਹੀਂ ਕਰਦਾ।

ਫਾਈਲ ਕਿਸਦੀ ਹੈ ਅਤੇ ਕਿੱਧਰ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ, ਜਾਂਚੋ

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਲਿੰਕ ਲੜੀ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਮਾਲਕੀ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿਹੜੀ ਫਾਈਲ ਪ੍ਰਮਾਣਿਕ ਹੈ। ਹੇਠਾਂ ਦਿੱਤਾ ਹਰ ਹੁਕਮ ਸਿਰਫ਼ ਸਥਿਤੀ ਪੜ੍ਹਦਾ ਹੈ।

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

ਪਹਿਲੀ ਲਾਈਨ ਲਿੰਕ ਅਤੇ ਉਸਦਾ ਟਾਰਗਿਟ ਇਕੱਠੇ ਛਾਪਦੀ ਹੈ, ਅਤੇ VPN ਸਕ੍ਰਿਪਟ ਦੀ ਮਾਲਕੀ ਵਾਲੀ ਆਮ ਫਾਈਲ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਰਿਜ਼ੌਲਵਰ ਉਸ ਲਿਖਤ ਨੂੰ ਕਦੇ ਇਨਪੁਟ ਨਹੀਂ ਮੰਨਦਾ। ਸਥਿਤੀ ਦਾ ਆਉਟਪੁਟ ਹਰ ਲਿੰਕ ਦੇ ਸਰਵਰ ਅਤੇ ਉਹ ਰਾਊਟਿੰਗ ਡੋਮੇਨ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ ਜੋ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਹਰ ਕਿਊਰੀ ਕਿੱਥੇ ਜਾਵੇਗੀ। nsswitch ਲਾਈਨ ਦੱਸਦੀ ਹੈ ਕਿ stub ਦੀ ਸਲਾਹ ਬਿਲਕੁਲ ਲਈ ਜਾਂਦੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਸ ਲਈ ਫਾਈਲ ਵਿੱਚ stub ਪਤਾ ਹੋਣ 'ਤੇ ਵੀ ਉੱਥੇ resolve ਨਾ ਹੋਵੇ ਤਾਂ ਕਿਊਰੀਆਂ ਸਥਾਨਕ ਸਰੋਤੇ ਤੱਕ ਪਹੁੰਚਦੀਆਂ ਹਨ ਪਰ ਵੰਡ ਕੋਈ ਸੰਭਾਲਦਾ ਨਹੀਂ। ਉਹ ਆਖਰੀ ਸੂਚੀ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ stub-resolv.conf ਤੋਂ ਬਿਨਾਂ ਹੋਸਟ ਇੱਥੇ ਦੱਸੀ ਵਿਵਸਥਾ ਨਹੀਂ ਚਲਾਉਂਦਾ।

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

ਲਿੰਕ ਦੇ ਮਾਲਕ ਕੋਲ ਮੁਰੰਮਤ ਕਰੋ

VPN ਕਨੈਕਸ਼ਨ ਨੂੰ ਆਪਣੇ ਸਰਵਰ ਅਤੇ ਡੋਮੇਨ ਆਪਣੇ ਲਿੰਕ 'ਤੇ ਦਰਜ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ, ਫਿਰ ਡਿਸਕਨੈਕਟ ਹੋਣ 'ਤੇ ਵਾਪਸ ਖਿੱਚ ਲੈਣੇ ਚਾਹੀਦੇ ਹਨ। NetworkManager ਦਾ resolved ਏਕੀਕਰਨ ਅਤੇ ਕਲਾਇੰਟ ਦਾ ਆਪਣਾ ਸਹਾਇਕ ਦੋਵੇਂ ਇਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੇ ਹਨ; ਸਿਰਫ਼ resolv.conf ਮੁੜ ਲਿਖਣ ਵਾਲੀ ਸਕ੍ਰਿਪਟ ਇਸ ਤਰ੍ਹਾਂ ਨਹੀਂ ਕਰਦੀ।

ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਲਿੰਕ 'ਤੇ ਰਨਟਾਈਮ ਸੈਟਿੰਗਾਂ ਵਿਧੀ ਦਿਖਾਉਂਦੀਆਂ ਹਨ। resolvectl dns tun0 10.40.0.53 ਇੱਕ ਸਰਵਰ ਜੋੜਦਾ ਹੈ, ਅਤੇ resolvectl domain tun0 '~corp.example' ਇੱਕ ਰਾਊਟਿੰਗ ਡੋਮੇਨ ਜੋੜਦਾ ਹੈ। ਟਿਲਡਾ (~) ਭਾਰ ਚੁੱਕਣ ਵਾਲਾ ਅੱਖਰ ਹੈ: ਇਹ ਉਸ ਪਿਛੇਤਰ ਦੀਆਂ ਕਿਊਰੀਆਂ ਨੂੰ ਇਸ ਲਿੰਕ ਤੱਕ ਸੀਮਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਬਾਕੀ ਸਭ ਨੂੰ ਸ਼ਾਂਤ ਛੱਡਦਾ ਹੈ, ਜਦਕਿ ਇਸ ਤੋਂ ਬਿਨਾਂ ਉਹੀ ਮੁੱਲ ਖੋਜ ਡੋਮੇਨ ਬਣ ਜਾਂਦਾ ਹੈ ਅਤੇ ਵੰਡ ਭਾਫ਼ ਬਣ ਜਾਂਦੀ ਹੈ। ਉਹ ਪਤੇ ਪ੍ਰਯੋਗਸ਼ਾਲਾ ਦੀਆਂ ਉਦਾਹਰਨਾਂ ਹਨ, ਸਥਾਈ ਸੰਰਚਨਾ ਨਹੀਂ। resolvectl query host.corp.example ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ ਅਤੇ ਪੜ੍ਹੋ ਕਿਹੜੇ ਲਿੰਕ ਨੇ ਜਵਾਬ ਦਿੱਤਾ।

ਦਰਜ ਸਰਵਰ ਨੂੰ ਫਿਰ ਵੀ ਰਾਹ ਚਾਹੀਦਾ ਹੈ। ਜਦੋਂ ਕਿਊਰੀ ਸਹੀ ਲਿੰਕ ਤੱਕ ਪਹੁੰਚ ਕੇ ਸਮਾਂ ਖ਼ਤਮ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਦੋਸ਼ ਰਿਜ਼ੌਲਵਰ ਦੀ ਮਾਲਕੀ ਵਿੱਚ ਨਹੀਂ, ਸੁਰੰਗ ਰਾਹੀਂ ਪਹੁੰਚ ਦੀ ਸਮਰੱਥਾ ਵਿੱਚ ਹੈ।

ਕੰਮ ਕਰਦੀ ਸਥਿਤੀ ਕਿਹੋ ਜਿਹੀ ਦਿਸਦੀ ਹੈ

ਸਿਹਤਮੰਦ ਨਤੀਜਾ ਤਿੰਨੇ ਦ੍ਰਿਸ਼ਾਂ ਵਿੱਚ ਇਕਸਾਰ ਹੁੰਦਾ ਹੈ: ਹਰ ਲਿੰਕ ਦੇ ਸਰਵਰ VPN ਵੱਲੋਂ ਦਿੱਤੇ ਨਾਲ ਮਿਲਦੇ ਹਨ, ਰਾਊਟਿੰਗ ਡੋਮੇਨ ਸਿਰਫ਼ ਅੰਦਰੂਨੀ ਪਿਛੇਤਰ ਢਕਦੇ ਹਨ, ਅਤੇ ਮਹੱਤਵਪੂਰਨ ਐਪਲੀਕੇਸ਼ਨ ਅੰਦਰੂਨੀ ਨਾਮ ਹੱਲ ਕਰਦੀ ਹੈ ਜਦਕਿ ਜਨਤਕ ਨਾਮ ਅਜੇ ਵੀ ਸਥਾਨਕ ਮਾਰਗ ਲੈਂਦਾ ਹੈ। ਇੱਕ ਸਫਲ ਕਿਊਰੀ ਉਸ ਸਹਿਮਤੀ ਤੋਂ ਘੱਟ ਸਾਬਤ ਕਰਦੀ ਹੈ।

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