SIGKILL ਤੋਂ ਬਾਅਦ OpenVPN DNS ਬਚਿਆ ਰਹਿੰਦਾ ਹੈ: ਪਹਿਲਾਂ ਮਾਲਕ ਦੀ ਜਾਂਚ ਕਰੋ

OpenVPN ਕਲਾਇੰਟ ਦੇ ਮਾਰੇ ਜਾਣ ਤੋਂ ਬਾਅਦ DNS ਹੱਲ ਹੋਣਾ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਪਹਿਲੀ ਪ੍ਰਵਿਰਤੀ /etc/resolv.conf ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਦੀ ਹੁੰਦੀ ਹੈ। ਉਹ ਬਦਲਾਅ ਕੰਮ ਕਰ ਰਹੇ ਰਿਜ਼ੋਲਵਰ ਨੂੰ ਤੋੜ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਅਸਲ ਪੁਰਾਣੀ ਸਥਿਤੀ ਕਿਤੇ ਹੋਰ ਹੁੰਦੀ ਹੈ। ਪਹਿਲਾਂ ਤੈਅ ਕਰਨ ਵਾਲਾ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਟਨਲ ਵੱਲੋਂ ਲਾਏ DNS ਸੈਟਿੰਗਾਂ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ, ਅਤੇ ਕੀ ਸਫ਼ਾਈ ਛੱਡ ਕੇ ਨਿਕਲਣਾ ਸੱਚਮੁੱਚ ਮਹੱਤਵਪੂਰਨ ਸੀ।

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

ਤੈਅ ਕਰੋ ਕਿ ਕਿਸ ਕਿਸਮ ਦਾ ਨਿਕਾਸ ਹੋਇਆ

Community ਸੰਸਕਰਣ ਵਿੱਚ OpenVPN ਵਿੱਚ SIGINT ਅਤੇ SIGTERM ਦੋਵੇਂ ਸ਼ਾਂਤ ਨਿਕਾਸ ਦੀਆਂ ਬੇਨਤੀਆਂ ਹਨ। SIGKILL ਫੜਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ: ਇਸਨੂੰ ਨਾ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ ਨਾ ਸੰਭਾਲਿਆ, ਇਸ ਲਈ ਕਿਸੇ ਸ਼ਟਡਾਊਨ ਰੁਟੀਨ ਨੂੰ ਚੱਲਣ ਦਾ ਮੌਕਾ ਨਹੀਂ ਮਿਲਦਾ। ਅਗਲੇ ਟਰਮੀਨਲ ਵਿੱਚ ਆਮ Ctrl+C SIGINT ਪੈਦਾ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਉਡੀਕ ਛੱਡ ਦੇਣ ਵਾਲਾ ਸੁਪਰਵਾਈਜ਼ਰ ਆਮ ਤੌਰ 'ਤੇ SIGKILL ਤੱਕ ਵਧਦਾ ਹੈ। ਫ਼ਰਕ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਸਿਰਫ਼ ਦੂਜਾ ਕੇਸ ਹੀ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ ਕਿ ਹੁੱਕ ਛੱਡੇ ਗਏ ਸਨ।

screen ਜਾਂ tmux ਦੇ ਅੰਦਰ ਚਲਾਉਣ ਨਾਲ ਇਹ ਨਹੀਂ ਬਦਲਦਾ ਕਿ Ctrl+C ਕਿਹੜਾ ਸਿਗਨਲ ਭੇਜਦਾ ਹੈ। ਟਰਮੀਨਲ ਆਮ ਤੌਰ 'ਤੇ ਕੀ ਕਰਦਾ ਹੈ ਦੀ ਬਜਾਏ ਪ੍ਰਕਿਰਿਆ ਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਪ੍ਰਾਪਤ ਕੀਤਾ, ਇਹ ਜਾਂਚੋ।

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

ਤੈਅ ਕਰੋ ਕਿ ਰਿਜ਼ੋਲਵਰ ਕਿਸਦਾ ਹੈ

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

ਮੁਰੰਮਤ ਦਾ ਹੁਕਮ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਮਾਲਕ ਦੀ ਪਛਾਣ ਕਰੋ। ਕਿਹੜਾ ਵਰਤੋਂ ਵਿੱਚ ਹੈ, ਇਸ ਆਧਾਰ 'ਤੇ ਉਸੇ ਲੱਛਣ ਦੇ ਤਿੰਨ ਵੱਖਰੇ ਸਹੀ ਜਵਾਬ ਹਨ।

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

down ਹੁੱਕ ਕੀ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

ਸਕ੍ਰਿਪਟ down TUN/TAP ਯੰਤਰ ਬੰਦ ਹੋਣ ਤੋਂ ਬਾਅਦ ਇੱਕ ਵਾਰ ਚੱਲਦੀ ਹੈ। ਜੋੜਨ ਨਾਲ down-pre ਉਹ ਕ੍ਰਮ ਉਲਟ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸਕ੍ਰਿਪਟ ਯੰਤਰ ਦੇ ਅਜੇ ਮੌਜੂਦ ਹੁੰਦਿਆਂ ਚੱਲਦੀ ਹੈ, ਜੋ ਜੀਵਤ ਲਿੰਕ ਦੀ ਲੋੜ ਵਾਲੇ ਸਹਾਇਕਾਂ ਲਈ ਜ਼ਰੂਰੀ ਹੈ।

ਕੋਈ ਵੀ ਨਿਰਦੇਸ਼ ਹੁੱਕ ਨੂੰ SIGKILL ਤੋਂ ਬਾਅਦ ਨਹੀਂ ਚਲਾਉਂਦਾ। ਅਧਿਕਾਰ ਵੀ down-pre ਰਾਹੀਂ ਬਹਾਲ ਨਹੀਂ ਹੁੰਦੇ: ਜੇ ਡੈਮਨ user ਜਾਂ group 'ਤੇ ਉੱਤਰਦਾ ਹੈ ਜਾਂ chroot ਵਿੱਚ ਦਾਖ਼ਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਹੁੱਕ ਉਸ ਪਹੁੰਚ ਨਾਲ ਚੱਲਦਾ ਹੈ ਜੋ ਇਹ ਛੱਡਦਾ ਹੈ। ਬੁਲਾਇਆ ਗਿਆ ਹੁੱਕ ਫਿਰ ਵੀ ਰਿਜ਼ੋਲਵਰ ਅੱਪਡੇਟ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ। OpenVPN ਹਵਾਲਾ ਸਿਗਨਲਾਂ ਅਤੇ ਕਾਲਬੈਕ ਜੀਵਨ-ਚੱਕਰ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ।

ਪ੍ਰਕਿਰਿਆ ਦੀ ਐਗਜ਼ਿਟ ਸਥਿਤੀ ਦੇ ਨਾਲ ਹੁੱਕ ਦੀ ਆਪਣੀ ਗਲਤੀ ਜਾਂਚੋ। ਖੁੰਝੀ ਸਫ਼ਾਈ ਅਤੇ ਅਸਫਲ ਸਫ਼ਾਈ ਰਿਜ਼ੋਲਵਰ ਵਿੱਚ ਇੱਕੋ ਜਿਹੀਆਂ ਅਤੇ ਲੌਗਾਂ ਵਿੱਚ ਵੱਖਰੀਆਂ ਦਿਸਦੀਆਂ ਹਨ।

ਅਸਲ ਵਿੱਚ ਬਚੀ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰੋ

systemd-resolved ਵਾਲੇ ਸਿਸਟਮ 'ਤੇ, resolvectl status ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਲਿੰਕ ਅਜੇ ਵੀ VPN ਦੇ DNS ਸਰਵਰ ਜਾਂ ਰਾਊਟਿੰਗ ਡੋਮੇਨ ਲੈ ਕੇ ਜਾਂਦਾ ਹੈ। ਉਹ ਲਿੰਕ ਜਾ ਚੁੱਕੇ ਕਨੈਕਸ਼ਨ ਦਾ ਹੋ ਸਕਦਾ ਹੈ, ਜਾਂ ਅਜੇ ਚਾਲੂ ਕਿਸੇ ਹੋਰ ਟਨਲ ਦਾ।

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

ਦੂਜਾ ਲਿੰਕ ਚੋਰੀ ਕੀਤੇ ਬਿਨਾਂ ਬਹਾਲ ਕਰੋ

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

ਸੋਧ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ /etc/resolv.conf ਪ੍ਰਬੰਧਿਤ ਸਿੰਬੋਲਿਕ ਲਿੰਕ ਹੈ, ਫਿਰ ਕਲਾਇੰਟ ਨੂੰ ਇੱਕ ਵਾਰ ਹੋਰ ਆਮ ਤਰੀਕੇ ਨਾਲ ਰੋਕੋ ਅਤੇ ਦੁਬਾਰਾ DNS ਵੇਖੋ। ਜੇ ਦੂਜੀ ਵਾਰ ਰੋਕਣ ਨਾਲ ਸਾਫ਼ ਹੋ ਜਾਵੇ, ਤਾਂ ਪਹਿਲੀ ਸਮੱਸਿਆ ਸੰਰਚਨਾ ਨਹੀਂ ਸੀ, ਜ਼ਬਰਦਸਤੀ ਨਿਕਾਸ ਸੀ।