resolvconf ਡੇਟਾਬੇਸ ਤੋਂ ਪੁਰਾਣੀ VPN ਰਿਕਾਰਡ ਹਟਾਉਣਾ

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

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ resolvconf ਸਥਿਤੀ ਦਾ ਮਾਲਕ ਹੈ

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

dpkg -l resolvconf | tail -1
ls -l /etc/resolv.conf
systemctl is-active resolvconf.service

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

ਡੇਟਾਬੇਸ ਵਿੱਚ ਇਨਪੁਟ ਹੁੰਦੇ ਹਨ, ਜਵਾਬ ਨਹੀਂ

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

sudo resolvconf --list
sudo resolvconf -i

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

ਕੁੰਜੀ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਥਾਂ ਆਉਟਪੁਟ ਤੋਂ ਕਾਪੀ ਕਰੋ। ਐਂਟਰੀ ਨੂੰ ਸਿਰਫ਼ ਇਸ ਲਈ tun0 ਨਹੀਂ ਕਿਹਾ ਜਾਂਦਾ ਕਿ ਕਿਸੇ ਪੁਰਾਣੀ ਸਕ੍ਰਿਪਟ ਨੇ ਉਹ ਨਾਮ ਵਰਤਿਆ ਸੀ।

ਸਾਬਤ ਕਰੋ ਕਿ ਰਿਕਾਰਡ ਦਾ ਕੋਈ ਮਾਲਕ ਨਹੀਂ

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

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

ਮਾਲਕ ਪ੍ਰਬੰਧਕ ਰਾਹੀਂ ਆਮ ਡਿਸਕਨੈਕਟ ਪਹਿਲਾ ਉਪਾਅ ਹੈ। ਇਹ ਉਹ ਵਾਪਸ ਲੈਂਦਾ ਹੈ ਜੋ ਉਸ ਕਨੈਕਸ਼ਨ ਨੇ ਸਥਾਪਿਤ ਕੀਤਾ ਸੀ ਅਤੇ ਹੋਰ ਸਪਲਾਇਰਾਂ ਨੂੰ ਅਛੂਤਾ ਛੱਡਦਾ ਹੈ।

ਹਟਾਉਣ ਅਤੇ ਦੁਬਾਰਾ ਲਿਖਣ ਦੀ ਜਾਂਚ ਕਰੋ

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

sudo resolvconf -d "RECORD_KEY_FROM_THE_LIST"
sudo resolvconf --list
resolvectl query host.corp.example || getent hosts host.corp.example

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

resolvconf -u ਸਿਰਫ਼ ਉਹ ਅੱਪਡੇਟ ਸਕ੍ਰਿਪਟਾਂ ਚਲਾਉਂਦਾ ਹੈ। ਇਹ ਕਦੇ ਵੀ ਪੁਰਾਣਾ ਰਿਕਾਰਡ ਨਹੀਂ ਪਛਾਣਦਾ ਜਾਂ ਮਿਟਾਉਂਦਾ, ਅਤੇ ਪੁਰਾਣੇ ਇਨਪੁਟਾਂ ਤੋਂ ਦੁਬਾਰਾ ਬਣਾਉਣ ਨਾਲ ਉਹੀ ਨਾ-ਲੋੜੀਂਦੀ ਫਾਈਲ ਬਣ ਜਾਂਦੀ ਹੈ।

ਮਾਰਿਆ ਗਿਆ ਡਿਸਕਨੈਕਟ ਹੁੱਕ ਰਿਕਾਰਡ ਪਿੱਛੇ ਛੱਡ ਦਿੰਦਾ ਹੈ

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

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

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