PAM ਪ੍ਰਮਾਣਿਕਤਾ ਹੱਥ ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ ਪਰ OpenVPN ਸੇਵਾ ਵਜੋਂ ਫੇਲ ਹੁੰਦੀ ਹੈ
root ਸ਼ੈੱਲ ਤੋਂ ਕੰਮ ਕਰਨ ਵਾਲਾ ਅਤੇ systemd ਹੇਠ ਫੇਲ ਹੋਣ ਵਾਲਾ PAM ਲੌਗਇਨ ਪਾਸਵਰਡ ਵੱਲ ਨਹੀਂ, ਸਹਾਇਕ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ, ਫਾਈਲ ਪਹੁੰਚ ਅਤੇ SELinux ਨੂੰ ਵੱਖ ਕਰੋ।
PAM ਰਾਹੀਂ ਪ੍ਰਮਾਣਿਕਤਾ ਸਫਲ ਹੋ ਸਕਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਕਲਾਇੰਟ ਨੂੰ ਹੱਥ ਨਾਲ ਚਲਾਉਂਦੇ ਹੋ, ਅਤੇ AUTH_FAILED ਨਾਲ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ ਜਦੋਂ systemd ਉਹੀ ਪਰੋਫ਼ਾਈਲ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਉਹਨਾਂ ਰਨਾਂ ਵਿਚਕਾਰ ਪਾਸਵਰਡ ਨਹੀਂ ਬਦਲਦਾ; ਬਦਲਣ ਵਾਲੀ ਚੀਜ਼ PAM ਨੂੰ ਸਵਾਲ ਪੁੱਛਣ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਦੁਆਲੇ ਪਾਬੰਦੀਆਂ ਦਾ ਸਮੂਹ ਹੈ। PAM ਇੱਕ ਸਹਾਇਕ ਰਾਹੀਂ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਜਿਸਦੀ ਆਪਣੇ ਪ੍ਰਮਾਣ ਬਦਲਣ ਦੀ ਸਮਰੱਥਾ ਬਿਲਕੁਲ ਉਹੀ ਚੀਜ਼ ਹੈ ਜੋ ਸਖ਼ਤ ਕੀਤੀ unit ਹਟਾਉਂਦੀ ਹੈ। ਸਮਰੱਥਾਵਾਂ ਦੀ ਸੂਚੀ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਸਹਾਇਕ ਅਤੇ ਉਸਨੂੰ ਲੋੜੀਂਦੀ ਸੀਮਾ ਲੱਭੋ।
unix_chkpwd ਉਹ ਬਾਈਨਰੀ ਹੈ ਜੋ PAM ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ
ਸਥਾਨਕ ਪਾਸਵਰਡ ਪ੍ਰਮਾਣਿਕਤਾ ਨਾਲ, pam_unix ਘੱਟ ਹੀ ਹੈਸ਼ ਫਾਈਲ ਆਪ ਪੜ੍ਹਦੀ ਹੈ। ਇਹ unix_chkpwd ਚਲਾਉਂਦੀ ਹੈ, ਜਿਸਨੂੰ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ setuid root ਜਾਂ setgid shadow ਵਜੋਂ ਸਥਾਪਿਤ ਕਰਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਇੱਕ ਪਾਸਵਰਡ ਉਸ ਪ੍ਰਕਿਰਿਆ ਵੱਲੋਂ ਜਾਂਚਿਆ ਜਾ ਸਕੇ ਜਿਸਨੂੰ /etc/shadow ਪੜ੍ਹਨ ਦਾ ਕੋਈ ਹੱਕ ਨਹੀਂ। ਉਹ ਪਛਾਣ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹਟਾ ਦਿਓ, ਸਹਾਇਕ ਜਾਂਚ ਪੂਰੀ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਇਸ ਲਈ ਮੋਡਿਊਲ ਇੱਕ ਆਮ ਪ੍ਰਮਾਣਿਕਤਾ ਫੇਲ ਲੌਟਦਾ ਹੈ।
ਫੇਰ ਫੇਲ ਕਲਾਇੰਟ ਨੂੰ ਦਿਸਣ ਵਾਲੇ ਹਰ ਲੌਗ ਵਿੱਚ ਪ੍ਰਮਾਣ ਸਮੱਸਿਆ ਵਾਂਗ ਦਿਸਦੀ ਹੈ। ਇਹੀ ਜਾਲ ਹੈ: ਕਲਾਇੰਟ ਦੱਸਦਾ ਹੈ ਜੋ PAM ਨੇ ਉਸਨੂੰ ਕਿਹਾ, ਅਤੇ PAM ਸਿਰਫ਼ ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਸਟੈਕ ਨੇ ਨਾਂ ਕਿਹਾ। ਸਹਾਇਕ ਨੂੰ root ਵਜੋਂ ਹੱਥ ਨਾਲ ਚਲਾਉਣਾ ਵੀ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ ਇਹ ਉਸ ਅਧਿਕਾਰ ਮਾਰਗ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜੋ ਸੇਵਾ ਕਦੇ ਨਹੀਂ ਵਰਤਦੀ। systemd ਨੇ ਜੋ unit ਅਸਲ ਵਿੱਚ ਲੋਡ ਕੀਤੀ ਪੜ੍ਹੋ, ਫੇਰ ਕੀਤੀ ਕੋਸ਼ਿਸ਼ ਲਈ ਸਿਸਟਮ ਲੌਗ ਪੜ੍ਹੋ। ਉਹ ਦੋ ਨਜ਼ਰੀਏ ਸੈਂਡਬਾਕਸ ਸਮੱਸਿਆ ਨੂੰ ਗਲਤ ਪਾਸਵਰਡ ਸਮੱਸਿਆ ਤੋਂ ਵੱਖ ਕਰਦੇ ਹਨ।
ਪਾਸਵਰਡ ਲੌਗ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ unit ਪੜ੍ਹੋ
ਪੈਕੇਜ ਕੀਤੀ unit ਕੋਈ ਅਜਿਹਾ drop-in ਲੈ ਕੇ ਆ ਸਕਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਲਿਖਿਆ, ਅਤੇ ਪ੍ਰਭਾਵੀ ਸੰਰਚਨਾ ਰਲੇ ਹੋਏ ਨਤੀਜਿਆਂ ਵਾਲੀ ਹੁੰਦੀ ਹੈ। unit ਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਛਾਪੋ ਜਿਵੇਂ systemd ਇਸਨੂੰ ਵੇਖਦਾ ਹੈ, ਨਾਲ ਹੀ ਉਹਨਾਂ ਸੈਂਡਬਾਕਸ ਸੈਟਿੰਗਾਂ ਨਾਲ ਜੋ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਸਹਾਇਕ ਆਪਣੇ ਆਪ ਨੂੰ ਉੱਚਾ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਇਸ ਪੜਾਅ ਤੇ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਵਾਲੀ ਜਾਂਚ ਕਾਫ਼ੀ ਹੈ।
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p CapabilityBoundingSet -p AmbientCapabilities -p NoNewPrivileges
journalctl -u [email protected] -bਪਹਿਲਾ ਕਮਾਂਡ ਦੱਸਦਾ ਹੈ ਕਿ unit ਅਤੇ ਇਸਦੇ drop-in ਕਿੱਥੋਂ ਆਉਂਦੇ ਹਨ, ਜੋ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਮਹੀਨਿਆਂ ਪਹਿਲਾਂ ਜੋੜਿਆ ਓਵਰਰਾਈਡ ਇਸ ਦੇ ਹੋਣ ਦੀ ਯਾਦ ਤੋਂ ਵੱਧ ਸਮਾਂ ਜੀਉਂਦਾ ਰਹਿੰਦਾ ਹੈ। ਦੂਜਾ ਉਹ ਸੈਂਡਬਾਕਸ ਮੁੱਲ ਛਾਪਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਤੇ ਅਗਲੇ ਦੋ ਭਾਗ ਨਿਰਭਰ ਕਰਦੇ ਹਨ।
ਜੋ ਤੁਸੀਂ ਵੇਖਦੇ ਹੋ ਉਸਨੂੰ ਉਸੇ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਅਤੇ ਵਰਜ਼ਨ ਦੇ ਕੰਮ ਕਰਦੇ ਹੋਸਟ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। User, CapabilityBoundingSet ਜਾਂ NoNewPrivileges ਵਿੱਚ ਫ਼ਰਕ ਇੱਕ ਠੋਸ ਸੁਰਾਗ ਹੈ; ਲਿਖਤੀ ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਫ਼ਰਕ ਨਹੀਂ। ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਮੁੱਲ ਲਿਖ ਲਓ, ਕਿਉਂਕਿ ਬਾਅਦ ਵਿੱਚ ਚੱਲਦੇ ਨਿਸ਼ਾਨੇ ਨਾਲ ਤੁਲਨਾ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ। ਜੇ ਸੇਵਾ ਖਾਲੀ ਸੀਮਾ-ਸਮੂਹ ਵਾਲੇ ਬਿਨਾਂ-ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਖਾਤੇ ਵਜੋਂ ਚੱਲਦੀ ਹੈ, ਤਾਂ ਸਹਾਇਕ ਕੋਲ ਕੰਮ ਕਰਨ ਲਈ ਲਗਭਗ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ।
ਪ੍ਰਮਾਣ ਬਦਲਾਅ, ਫਾਈਲ ਪਹੁੰਚ ਅਤੇ ਨੀਤੀ ਤਿੰਨ ਸੀਮਾਵਾਂ ਹਨ
exec ਦੌਰਾਨ ਕੀ ਹੁੰਦਾ ਹੈ ਉਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। setuid ਬਾਈਨਰੀ ਜਾਂ file capabilities ਵਾਲੀ ਫਾਈਲ ਪ੍ਰਮਾਣ ਬਦਲਾਅ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਨਤੀਜੇ ਵਜੋਂ ਮਿਲੀ ਪਛਾਣ ਕਾਲ ਕਰਨ ਵਾਲੇ ਦੀ ਜਾਰੀ ਰਹਿਣ ਵਾਲੀ ਨਹੀਂ ਹੁੰਦੀ। ਸੀਮਾ-ਸਮੂਹ ਸੀਮਤ ਕਰਦਾ ਹੈ ਕਿ ਅਜਿਹੀ ਬਾਈਨਰੀ ਕੀ ਲੈ ਸਕਦੀ ਹੈ, ਅਤੇ NoNewPrivileges setuid, setgid ਅਤੇ file capabilities ਲੈਣ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰੋਕਦਾ ਹੈ। ਇਹਨਾਂ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸਹਾਇਕ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਸੇਵਾ ਦਾ ਹਰ ਹੋਰ ਕੰਮ ਬਿਨਾਂ ਨੁਕਸਾਨ ਰਹਿੰਦਾ ਹੈ।
ਫੇਰ ਚੌੜੇ ਵਿਵੇਕਾਧੀਨ ਬਾਈਪਾਸ ਨੂੰ ਤੰਗ ਪੜ੍ਹਨ ਪਹੁੰਚ ਤੋਂ ਵੱਖ ਕਰੋ। CAP_DAC_OVERRIDE ਲਗਭਗ ਹਰ ਥਾਂ ਵਿਵੇਕਾਧੀਨ ਜਾਂਚਾਂ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ CAP_DAC_READ_SEARCH ਆਪਣੇ ਵਾਧੂ ਅਧਿਕਾਰਾਂ ਨਾਲ ਪੜ੍ਹਨ ਅਤੇ ਡਾਇਰੈਕਟਰੀ ਟ੍ਰੈਵਰਸਲ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ। ਇਹ ਵੱਖਰੇ ਪ੍ਰਭਾਵ ਘੇਰੇ ਵਾਲੇ ਵੱਖਰੇ ਸਾਧਨ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ PAM ਨੂੰ shadow ਫਾਈਲ ਪੜ੍ਹਨ ਦਿਓ ਲਿਖਣ ਦਾ ਤਰੀਕਾ ਨਹੀਂ।
ਅੰਤ ਵਿੱਚ ਪੁੱਛੋ ਕਿ ਲਾਜ਼ਮੀ ਨੀਤੀ ਇਸ ਕਾਰਵਾਈ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ। Linux ਸਮਰੱਥਾ SELinux ਨੂੰ ਓਵਰਰਾਈਡ ਨਹੀਂ ਕਰਦੀ, ਅਤੇ ਇਸਦਾ ਹੋਣਾ ਕਿਸੇ ਕਿਸਮ ਦੇ ਲਾਗੂ ਕਰਨ ਵਾਲੇ ਨਿਯਮ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਫਾਈਲ ਪਹੁੰਚ ਤੋਂ ਇਨਕਾਰ ਅਤੇ ਸਮਰੱਥਾ ਤੋਂ ਇਨਕਾਰ ਨੂੰ ਵੱਖਰੇ ਸਬੂਤ ਮੰਨੋ, ਕਿਉਂਕਿ ਉਹ ਵੱਖਰੇ ਸੁਧਾਰ ਅਤੇ ਅਕਸਰ ਵੱਖਰੇ ਮਾਲਕ ਦੱਸਦੇ ਹਨ। denied ਸ਼ਬਦ ਦੀ ਥਾਂ ਰਿਕਾਰਡ ਦਾ ਹਰ ਖੇਤਰ ਪੜ੍ਹੋ। ਕਿਹੜੀ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਨੇ ਕਾਰਵਾਈ ਕੀਤੀ, ਇਹ ਕਿਹੜੇ ਡੋਮੇਨ ਵਿੱਚ ਚੱਲੀ, ਕਿਸ ਕਿਸਮ ਦੇ ਨਿਸ਼ਾਨੇ ਨੂੰ ਛੂਹਿਆ, ਕਿਹੜੀ ਸ਼੍ਰੇਣੀ ਦਾ ਆਬਜੈਕਟ ਸ਼ਾਮਲ ਸੀ ਅਤੇ ਨੀਤੀ ਨੇ ਕਿਹੜੀ ਇਜਾਜ਼ਤ ਨਕਾਰੀ - ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਜਵਾਬ ਨੂੰ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਤੰਗ ਕਰਦਾ ਹੈ।
ਇਨਕਾਰ ਨੂੰ ਆਡਿਟ ਲੌਗ ਵਿੱਚੋਂ ਕੱਢੋ
enforcing ਮੋਡ ਵਾਲੇ ਹੋਸਟ ਤੇ, ਆਡਿਟ ਟ੍ਰੇਲ ਹੀ ਇੱਕੋ ਥਾਂ ਹੈ ਜੋ ਇਨਕਾਰ ਦਰਜ ਕਰਦੀ ਹੈ। ਤਾਜ਼ਾ ਘਟਨਾਵਾਂ ਪੁੱਛੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਫੇਲ ਹੋਏ ਲੌਗਇਨ ਦੀ ਸਮਾਂ-ਮੋਹਰ ਦੇ ਹਿਸਾਬ ਨਾਲ ਪੜ੍ਹੋ, ਨਾ ਕਿ ਉਸ ਸਮੇਂ ਦੇ ਹਿਸਾਬ ਨਾਲ ਜਦੋਂ ਤੁਸੀਂ ਜਾਂਚ ਸ਼ੁਰੂ ਕੀਤੀ।
ausearch -m AVC,USER_AVC -ts recentਖਾਲੀ ਨਤੀਜਾ ਬੇਗੁਨਾਹ ਹੋਣ ਦਾ ਸਬੂਤ ਨਹੀਂ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਜਾਂ ਤਾਂ ਆਡਿਟ ਇਕੱਠਾ ਨਹੀਂ ਕਰ ਰਿਹਾ, ਜਾਂ ਤੁਹਾਡੀ ਵਿੰਡੋ ਨੇ ਕੋਸ਼ਿਸ਼ ਗੁਆ ਦਿੱਤੀ, ਅਤੇ ਨੀਤੀ ਨੂੰ ਬਾਹਰ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਸੰਭਾਵਨਾਵਾਂ ਬਾਹਰ ਕੱਢਣੀਆਂ ਪੈਣਗੀਆਂ।
Red Hat ਦੀ SELinux ਸਮੱਸਿਆ-ਨਿਵਾਰਨ ਗਾਈਡ ਲੇਬਲ ਅਤੇ ਸੰਰਚਨਾ ਜਾਂਚਾਂ ਨੂੰ ਇਜਾਜ਼ਤ ਨਿਯਮ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਰੱਖਦੀ ਹੈ, ਜੋ ਇਸ ਸਮੱਸਿਆ ਲਈ ਵੀ ਸਹੀ ਕ੍ਰਮ ਹੈ। ਗਲਤ ਲੇਬਲ ਵਾਲੀ ਸਹਾਇਕ ਬਾਈਨਰੀ ਅਤੇ ਨੀਤੀ ਵਿੱਚ ਪਾੜਾ ਇੱਕੋ ਜਿਹੇ ਇਨਕਾਰ ਪੈਦਾ ਕਰਦੇ ਹਨ ਪਰ ਵੱਖਰੇ ਸੁਧਾਰ ਲੋੜਦੇ ਹਨ। ਲੇਬਲ ਗਲਤੀ ਲਈ ਇਜਾਜ਼ਤ ਨਿਯਮ ਬਣਾਉਣਾ ਨੁਕਸ ਨੂੰ ਲੁਕਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਅਗਲੇ ਪੈਕੇਜ ਅਪਡੇਟ ਨੂੰ ਇਸਨੂੰ ਮੁੜ ਲਿਆਉਣ ਦਿੰਦਾ ਹੈ। ਕੋਈ ਵੀ ਨੀਤੀ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਸਥਾਪਿਤ ਸਹਾਇਕ ਤੇ ਲੇਬਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
ਇੱਕ ਸਫਲ ਅਤੇ ਇੱਕ ਨਾਕਾਰੀ ਲੌਗਇਨ ਨਾਲ ਬਦਲਾਅ ਸਾਬਤ ਕਰੋ
ਸਿਰਫ਼ ਉਹ ਸੀਮਾ ਬਦਲੋ ਜੋ ਤੁਸੀਂ ਸਾਬਤ ਕੀਤੀ, ਫੇਰ ਦੋਵੇਂ ਨਤੀਜੇ ਪਰਖੋ। ਜਿਸ ਖਾਤੇ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਉਸਨੂੰ ਸਫਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਗਲਤ ਪਾਸਵਰਡ ਵਾਲੇ ਖਾਤੇ ਨੂੰ ਅਜੇ ਵੀ ਫੇਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜਿਹੜਾ ਬਦਲਾਅ ਹਰ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਸਫਲ ਕਰ ਦਿੰਦਾ ਹੈ ਉਸਨੇ ਪ੍ਰਮਾਣਿਕਤਾ ਸੁਧਾਰਨ ਦੀ ਥਾਂ ਹਟਾ ਦਿੱਤੀ ਹੈ।
ਅਸਲ ਕਨੈਕਸ਼ਨ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਅਤੇ ਤੁਰੰਤ ਬਾਅਦ journal ਪੜ੍ਹੋ। ਸੁਧਾਰ ਸਾਬਤ ਕਰਨ ਵਾਲੀ ਲਾਈਨ ਉਸ ਕੋਸ਼ਿਸ਼ ਲਈ pam_unix(openvpn:auth) ਐਂਟਰੀ ਹੈ: ਇਸ ਵਿੱਚ ਪ੍ਰਮਾਣਿਕਤਾ ਸਫਲ ਲਿਖਿਆ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕੋਈ AVC ਰਿਕਾਰਡ ਉਸੇ ਸਕਿੰਟ ਦਾ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।
journalctl -u [email protected] -n 30 --no-pager
ss -tnp | grep openvpnਕੰਮ ਕਰਦੀ ਟਨਲ ਨੂੰ ਮੁੜ-ਕਨੈਕਟ ਦੀ ਵੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਸੈਂਡਬਾਕਸ ਬਦਲਾਅ ਦੂਜੇ ਕਨੈਕਸ਼ਨ ਨੂੰ ਪਹਿਲੇ ਨਾਲੋਂ ਵੱਧ ਵਾਰ ਤੋੜਦੇ ਹਨ। ਮੁੜ-ਕਨੈਕਟ ਤੋਂ ਬਾਅਦ ਸਥਾਪਿਤ ਸਾਕਟ ਦੀ ਜਾਂਚ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਉਹੀ unit ਅਜੇ ਵੀ ਇਸਦੀ ਸੇਵਾ ਕਰ ਰਹੀ ਹੈ।