VPN DNS ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ .local ਨਾਮ ਅਜੇ ਵੀ ਅਸਫਲ ਹੁੰਦੇ ਹਨ: ਉਹਨਾਂ ਨੂੰ ਕੌਣ ਹੱਲ ਕਰਦਾ ਹੈ?

ਇੱਕੋ VPN ’ਤੇ ਦੋ ਮਸ਼ੀਨਾਂ, ਇੱਕੋ ਹੋਸਟਨਾਮ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਇਸਨੂੰ ਹੱਲ ਕਰਦੀ ਹੈ: ਫ਼ਰਕ ਆਮ ਤੌਰ ’ਤੇ ਟਨਲ ਨਹੀਂ, ਸਗੋਂ ਇਹ ਹੈ ਕਿ ਕਿਹੜੇ ਰਿਜ਼ੋਲਵਰ ਨੇ ਜਵਾਬ ਦਿੱਤਾ। Linux ਡੈਸਕਟਾਪ ’ਤੇ ਉਹ ਨਾਮ ਨਾਮ ਸੇਵਾ ਸਵਿੱਚ ਵਿੱਚੋਂ, systemd-resolved ਦੇ ਸਟਬ ਵਿੱਚੋਂ, ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਨਾਲ ਲਿਆਏ ਰਿਜ਼ੋਲਵਰ ਵਿੱਚੋਂ ਲੰਘ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਉਸੇ ਸਫ਼ਿਕਸ ’ਤੇ ਆਪਣਾ ਨਿਯਮ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਨਿਯਮ ਸਫ਼ਿਕਸ ’ਤੇ ਹੀ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ, ਕਿਉਂਕਿ .local ਨਿਰਪੱਖ ਲੇਬਲ ਨਹੀਂ ਹੈ। ਕੁਝ ਵੀ ਕਿਸ ਕ੍ਰਮ ਵਿੱਚ ਚੱਲਦਾ ਹੈ ਇਹ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਕਰੋ ਕਿ ਅਸਫਲ ਪ੍ਰੋਗਰਾਮ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਰਾਹ ਲੈਂਦਾ ਹੈ।

ਦੋ ਰਿਜ਼ੋਲਵਰ, ਦੋ ਵੱਖਰੇ ਜਵਾਬ

ਰਵਾਇਤੀ glibc ਖੋਜ nsswitch.conf ਦੀ hosts: ਲਾਈਨ ਵਿੱਚੋਂ ਲੰਘਦੀ ਹੈ ਅਤੇ ਇੱਕ ਦੇ ਜਵਾਬ ਦੇਣ ਤੱਕ ਹਰ ਮਾਡਿਊਲ ਨੂੰ ਵਾਰੀ-ਵਾਰੀ ਪੁੱਛਦੀ ਹੈ। ਸਟਬ ਲਿਸਨਰ ਰਾਹੀਂ systemd-resolved ਨਾਲ ਗੱਲ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਇਸਦੀ ਬਜਾਏ ਇੱਕੋ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪੁੱਛਦਾ ਹੈ, ਅਤੇ ਉਹ ਪ੍ਰਕਿਰਿਆ ਹਰ ਲਿੰਕ ਲਈ ਨੀਤੀ ਅਤੇ ਆਪਣੇ ਖਾਸ ਕੇਸ ਲਾਗੂ ਕਰਦੀ ਹੈ। ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਆਪਣਾ ਰਿਜ਼ੋਲਵਰ ਲਿਆਉਂਦੀ ਹੈ, ਜਾਂ ਅਜਿਹਾ ਕਰਨ ਵਾਲੀ ਲਾਇਬ੍ਰੇਰੀ ਲਿੰਕ ਕਰਦੀ ਹੈ, ਉਹ ਦੋਵਾਂ ਨੂੰ ਬਾਈਪਾਸ ਕਰ ਸਕਦੀ ਹੈ। ਇਸ ਲਈ ਇੱਕ ਹੋਸਟਨਾਮ ਦੇ ਇੱਕ ਮਸ਼ੀਨ ’ਤੇ ਤਿੰਨ ਮਾਲਕ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਨੂੰ ਪਤਾ ਹੈ ਕਿ VPN ਦਾ ਕੀ ਮਤਲਬ ਸੀ।

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

ਕਿਹੜੇ ਆਦੇਸ਼ ਨੇ ਅਸਲ ਵਿੱਚ ਤੁਹਾਡੇ ਰਿਜ਼ੋਲਵਰ ਨੂੰ ਪੁੱਛਿਆ

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

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

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

ਕਿਉਂ .local ਤੁਹਾਡੇ unicast ਜ਼ੋਨ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ

systemd-resolved ਦਾ ਹਵਾਲਾ ਦੱਸਦਾ ਹੈ ਕਿ .local ’ਤੇ ਖਤਮ ਹੋਣ ਵਾਲੇ ਬਹੁ-ਲੇਬਲ ਨਾਮ, mDNS ਸਮਰੱਥ ਹੋਣ ’ਤੇ ਆਮ unicast DNS ਦੀ ਬਜਾਏ ਆਮ ਤੌਰ ’ਤੇ multicast DNS ’ਤੇ ਜਾਂਦੇ ਹਨ। RFC 6762 ਉਸ ਨਾਮ ਥਾਂ ਨੂੰ link-local multicast ਲਈ ਰਾਖਵਾਂ ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ ਕੋਈ ਕਾਰਪੋਰੇਟ ਜ਼ੋਨ ਸਹੀ ਰਿਕਾਰਡ ਰੱਖ ਸਕਦਾ ਹੈ ਜੋ ਉਸ ਸਫ਼ਿਕਸ ਲਈ ਕਦੇ ਨਹੀਂ ਪੁੱਛਿਆ ਜਾਂਦਾ। ਟਨਲ ਰਿਜ਼ੋਲਵਰ ਨੂੰ ਸੰਪੂਰਨ ਢੰਗ ਨਾਲ ਰਾਊਟ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਦੌੜ ਹਾਰ ਸਕਦਾ ਹੈ। ਕੈਸ਼ ਤੋਂ ਸਫਲ ping ਉਸ ਖੋਜ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ ਜੋ ਹੁਣੇ ਹੋਈ ਹੈ।

ਇੱਕ ਦਸਤਾਵੇਜ਼ੀ ਅਪਵਾਦ ਹੈ, ਅਤੇ ਇਹ ਇਹਨਾਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ ਕੇਸ ਹੱਲ ਕਰਦਾ ਹੈ: ਜਦੋਂ ਲਿੰਕ ਉਸ ਸਫ਼ਿਕਸ ਨੂੰ ਖੋਜ ਡੋਮੇਨ ਜਾਂ ਰਾਊਟਿੰਗ ਡੋਮੇਨ ਘੋਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਡੈਮਨ ਇਸਨੂੰ unicast ਰਾਹ ’ਤੇ ਰੱਖਦਾ ਹੈ ਅਤੇ multicast ਖਾਸ ਕੇਸ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਇਹ ਹਰ ਲਿੰਕ ਦੀ ਨੀਤੀ ਹੈ, ਵਿਸ਼ਵਵਿਆਪੀ ਤਰਜੀਹ ਨਹੀਂ। ਇੱਕੋ VPN ਸਰਵਰ ਵਾਲੀਆਂ ਦੋ ਮਸ਼ੀਨਾਂ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰ ਸਕਦੀਆਂ ਹਨ ਜਦੋਂ ਇੱਕ ਨੈੱਟਵਰਕ ਪ੍ਰੋਫ਼ਾਈਲ ਡੋਮੇਨ ਘੋਸ਼ਿਤ ਕਰਦੀ ਹੈ ਅਤੇ ਦੂਜੀ ਨਹੀਂ, ਇਸ ਲਈ ਯਾਦ ਵਿੱਚ ਰਹਿ ਗਈ ਪ੍ਰੋਫ਼ਾਈਲ ਨਹੀਂ, ਸਰਗਰਮ ਪ੍ਰੋਫ਼ਾਈਲ ਪੜ੍ਹੋ।

ਸੰਕੁਚਿਤ ਅਪਵਾਦ ਵਿਸ਼ਵਵਿਆਪੀ ਮੁੜ-ਕ੍ਰਮਬੱਧੀ ਨੂੰ ਹਰਾਉਂਦਾ ਹੈ

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

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

ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਕੀ ਸਾਬਤ ਕਰਨਾ ਹੈ

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

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

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