/etc/resolv.conf ਲਈ ਮੁਕਾਬਲਾ ਕਰਦੀਆਂ ਦੋ Linux ਸੇਵਾਵਾਂ ਨੂੰ ਰੋਕੋ

DNS ਵਾਰ-ਵਾਰ ਪੁਰਾਣੀ ਹਾਲਤ ਵਿੱਚ ਪਰਤਦਾ ਹੈ, VPN ਦੁਬਾਰਾ ਕਨੈਕਟ ਹੋਣਾ ਤੁਹਾਡੀ ਸੋਧ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਆਖ਼ਿਰ ਟੀਮ ਵਿੱਚ ਕੋਈ ਫਾਈਲ ਲਾਕ ਕਰਨ ਦਾ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ। ਇਹ ਕ੍ਰਮ ਲੱਛਣ ਹੈ, ਹੱਲ ਨਹੀਂ: ਦੋਵੇਂ ਹਿੱਸੇ ਮੰਨਦੇ ਹਨ ਕਿ /etc/resolv.conf ਉਨ੍ਹਾਂ ਦੀ ਹੈ, ਅਤੇ ਆਖ਼ਿਰ ਵਿੱਚ ਜੋ ਲਿਖਦਾ ਹੈ ਉਹ ਜਿੱਤਦਾ ਹੈ। ਫਾਈਲ ਲਾਕ ਕਰਨ ਨਾਲ ਮਾਲਕੀ ਦਾ ਟਕਰਾਅ ਹੱਲ ਨਹੀਂ ਹੁੰਦਾ, ਇਹ ਸਿਰਫ਼ ਉਸਨੂੰ ਲੁਕਾਉਂਦਾ ਹੈ ਅਤੇ ਉਸੇ ਸਮੇਂ ਉਹ ਹਿੱਸਾ ਤੋੜਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਚਾਹੁੰਦੇ ਸੀ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਚਾਰ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ ਅਤੇ ਬੰਦੋਬਸਤ ਨੂੰ ਉਸ ਪੱਧਰ 'ਤੇ ਸੋਧੋ ਜੋ ਇਸਦਾ ਮਾਲਕ ਹੈ, ਫਾਈਲ 'ਤੇ ਨਹੀਂ।

ਜਾਂਚ 1: ਕੀ ਇਹ ਸਿੰਬੋਲਿਕ ਲਿੰਕ ਹੈ, ਅਤੇ ਕਿੱਥੇ

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

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

systemd-resolved ਦੇ stub ਰਾਹ ਵੱਲ ਲਿੰਕ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਫਾਈਲ ਦੀ ਸਮੱਗਰੀ ਤਿਆਰ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਹੱਥੀਂ ਸੰਪਾਦਨ ਅਗਲੀ ਘਟਨਾ ਵਿੱਚ ਉੱਤੇ ਲਿਖਿਆ ਜਾਵੇਗਾ। nameserver ਲਾਈਨਾਂ ਵਾਲੀ ਸਾਧਾਰਨ ਫਾਈਲ ਆਮ ਤੌਰ 'ਤੇ ਕਨੈਕਟ ਹੋਣ ਵੇਲੇ ਚੱਲਣ ਵਾਲਾ ਕਲਾਇੰਟ ਜਾਂ DHCP ਹੁੱਕ ਲਿਖਦਾ ਹੈ। ਦੋਵੇਂ ਜਾਇਜ਼ ਹਨ; ਅਹਿਮ ਗੱਲ ਇਹ ਹੈ ਕਿ ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਡੇ ਕੋਲ ਕਿਹੜੀ ਹੈ, ਇਹ ਜਾਣੋ।

ਜਾਂਚ 2: ਕਿਹੜਾ ਡੈਮਨ ਚੱਲ ਰਿਹਾ ਹੈ

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

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

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

NetworkManager ਦੀ ਆਪਣੀ ਸੰਰਚਨਾ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਬੈਕਐਂਡ ਵਰਤਣਾ ਹੈ। ਮੁੱਖ ਸੰਰਚਨਾ ਫਾਈਲ ਵਿੱਚ ਇਸਦੀ dns= ਸੈਟਿੰਗ ਇਸਦੇ ਅੰਦਰੂਨੀ ਰਿਜ਼ੋਲਵਰ, dnsmasq, systemd-resolved ਅਤੇ none ਵਿਚਕਾਰ ਚੋਣ ਕਰਦੀ ਹੈ, ਅਤੇ ਵੰਡ ਨੇ ਤੁਹਾਡੇ ਲਈ ਚੁਣਿਆ ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਹੋਸਟ 'ਤੇ “DNS ਠੀਕ ਕਰਨ” ਦਾ ਮਤਲਬ ਕੀ ਹੈ ਇਹ ਤੈਅ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਸੈਟਿੰਗ ਪੜ੍ਹੋ।

ਜਾਂਚ 3: VPN ਕਲਾਇੰਟ ਨੂੰ ਕੀ ਲਿਖਣ ਦੀ ਇਜਾਜ਼ਤ ਹੈ

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

WireGuard ਦੀ ਸਥਿਤੀ ਆਕਾਰ ਵਿੱਚ ਸਮਾਨ ਹੈ: ਇੰਟਰਫੇਸ ਸੰਰਚਨਾ ਆਪ DNS ਦਾ ਪ੍ਰਬੰਧ ਨਹੀਂ ਕਰਦੀ, ਆਲੇ-ਦੁਆਲੇ ਦੇ ਸਾਧਨ ਕਰਦੇ ਹਨ, ਰਿਜ਼ੋਲਵਰ ਸਹਾਇਕ ਜਾਂ resolved ਏਕੀਕਰਨ ਰਾਹੀਂ। ਜੇ ਅਜਿਹੇ ਦੋ ਸਹਾਇਕ ਇੰਸਟਾਲ ਹੋਣ, ਤਾਂ ਦੋਵੇਂ ਕਨੈਕਟ ਹੋਣ ਵੇਲੇ ਆਪਣਾ ਦੁਨੀਆ ਦਾ ਨਜ਼ਰੀਆ ਲਾਗੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਗੇ।

ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਕਲਾਇੰਟ ਦੇ up ਅਤੇ down ਹੁੱਕ ਪੜ੍ਹੋ। /etc/openvpn/up.sh ਜਾਂ ਸਮਾਨ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਕੁਝ ਲਾਈਨਾਂ shell ਉਸ ਵਿਵਹਾਰ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀਆਂ ਹਨ ਜੋ ਨਹੀਂ ਤਾਂ ਬੇਤਰਤੀਬ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਮੁਕਾਬਲਾ ਕਰਨ ਦੀ ਥਾਂ ਸਹਿਯੋਗ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਨ ਦੀ ਥਾਂ ਵੀ ਉਹੀ ਹੈ।

ਜਾਂਚ 4: ਇਸਨੂੰ ਮਾਲਕ ਕੋਲ ਠੀਕ ਕਰੋ, ਫਾਈਲ ਵਿੱਚ ਨਹੀਂ

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

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

ਜਿੱਥੇ ਦੋ ਹਿੱਸਿਆਂ ਨੂੰ ਸੱਚਮੁੱਚ ਇਕੱਠੇ ਰਹਿਣਾ ਹੈ, ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖਰੇ ਕੰਮ ਦਿਓ। ਨੈੱਟਵਰਕ ਮੈਨੇਜਰ ਨੂੰ ਇੰਟਰਫੇਸ-ਪੱਧਰੀ ਸੰਰਚਨਾ ਰੱਖਣ ਦਿਓ, VPN ਕਲਾਇੰਟ ਨੂੰ ਉਸੇ ਏਕੀਕਰਨ ਰਾਹੀਂ ਹਰ ਲਿੰਕ ਦਾ DNS ਅਤੇ ਡੋਮੇਨ ਯੋਗਦਾਨ ਦੇਣ ਦਿਓ, ਅਤੇ ਫਾਈਲ ਸਿੱਧੀ ਲਿਖਣ ਵਾਲੀ ਤੀਜੀ ਸਕ੍ਰਿਪਟ ਹਟਾ ਦਿਓ। systemd-resolved ਦਾ ਦਸਤਾਵੇਜ਼ ਇਸਦੇ ਸਮਰਥਿਤ ਮੋਡਾਂ ਅਤੇ ਹਰ ਇੱਕ /etc/resolv.conf ਵਿੱਚ ਕੀ ਦਿਖਾਉਂਦਾ ਹੈ, ਦੱਸਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਕਿੰਨੀ ਨੀਤੀ ਰੱਖਣੀ ਹੈ ਉਸ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਮੋਡ ਚੁਣੋ। ਜੇ ਸਪਲਿਟ DNS ਮਹੱਤਵਪੂਰਨ ਹੈ, ਤਾਂ ਹਰ ਲਿੰਕ ਦੇ ਡੋਮੇਨਾਂ ਵਾਲੀ stub ਬੰਦੋਬਸਤ ਉਸਨੂੰ ਬਚਾਉਂਦੀ ਹੈ, ਜਦਕਿ upstream ਸਰਵਰ ਫਾਈਲ ਵਿੱਚ ਕਾਪੀ ਕਰਨ ਵਾਲਾ ਮੋਡ ਉਸਨੂੰ ਚੁੱਪਚਾਪ ਸਮਤਲ ਕਰ ਦਿੰਦਾ ਹੈ।

ਦੁਬਾਰਾ ਕਨੈਕਸ਼ਨ ਤੋਂ ਬਾਅਦ ਜਾਂਚੋ, ਸੰਪਾਦਨ ਤੋਂ ਬਾਅਦ ਨਹੀਂ

ਤੁਹਾਡੀ ਤਬਦੀਲੀ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਸਹੀ ਦਿਸਦੀ ਫਾਈਲ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ, ਕਿਉਂਕਿ ਅਗਲੀ ਘਟਨਾ ਅਜੇ ਨਹੀਂ ਹੋਈ। ਉਹ ਕ੍ਰਮ ਚਲਾਓ ਜੋ ਪਹਿਲਾਂ ਇਸਨੂੰ ਤੋੜਦਾ ਸੀ: ਟਨਲ ਹੇਠਾਂ ਲਾਹੋ ਅਤੇ ਦੁਬਾਰਾ ਚੁੱਕੋ, DHCP ਲੀਜ਼ ਨਵੀਨੀਕਰਨ ਕਰੋ ਜਾਂ ਇੰਟਰਫੇਸ ਬਦਲੋ, ਫਿਰ ਉਹੀ ਮੁੱਲ ਦੁਬਾਰਾ ਪੜ੍ਹੋ।

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

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

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