OpenVPN ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦਾ: ਪਹਿਲੀ ਲਾਈਨ ਪੜ੍ਹੋ, ਕਾਨਫਿਗ ਨਹੀਂ

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

ਤਿੰਨ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਵਾਲੇ ਕਮਾਂਡ ਤੁਹਾਨੂੰ ਉੱਥੇ ਪਹੁੰਚਾਉਂਦੇ ਹਨ: ਪਹਿਲਾਂ journalctl -u openvpn@server -b --no-pager, ਫਿਰ systemctl status openvpn@server, ਅਤੇ UDP ਸਰੋਤਿਆਂ ਤੇ ਉਨ੍ਹਾਂ ਦੇ ਮਾਲਕਾਂ ਲਈ ss -lunp।

ਪਹਿਲੀ ਲਾਈਨ ਹੀ ਸ਼ਾਖਾ ਚੁਣਦੀ ਹੈ

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

ਮੂਲ ਲਾਈਨ ਲੁਕਾਉਣ ਵਾਲੇ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਲੂਪ ਵੱਲ ਧਿਆਨ ਦਿਓ। ਰੀਸਟਾਰਟ ਨੀਤੀ ਵਾਲਾ ਯੂਨਿਟ ਪਹਿਲੀ ਫੇਲ੍ਹਤਾ ਨੂੰ ਦਰਜਨਾਂ ਸਮਾਨ ਫੇਲ੍ਹਤਾਵਾਂ ਹੇਠ ਦੱਬ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਯੂਨਿਟ ਅਨੁਸਾਰ ਫਿਲਟਰ ਕਰਕੇ ਉੱਪਰ ਤੋਂ ਪੜ੍ਹੀ journalctl -b ਪੂਛ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ।

ਹੋਰ ਕੌਣ 1194 ਪੋਰਟ ਫੜੀ ਬੈਠਾ ਹੈ

ਦੋਸ਼ੀ ਆਮ ਤੌਰ ’ਤੇ ਕੋਈ ਜਾਣ-ਬੁੱਝ ਕੇ ਸੈੱਟ ਕੀਤਾ ਦੂਜਾ ਸਰਵਰ ਨਹੀਂ ਹੁੰਦਾ। ਦੂਜੇ ਟਰਮੀਨਲ ਵਿੱਚ ਅਜੇ ਜੀਵਤ ਹੱਥੀਂ ਸ਼ੁਰੂ ਕੀਤਾ ਕਲਾਇੰਟ, ਉਹੀ ਪੋਰਟ ਚੁਣ ਲੈਣ ਵਾਲਾ ਦੂਜਾ ਪ੍ਰੋਫਾਈਲ, ਜਾਂ ਜਿਸ ਦਾ ਆਪਣਾ ਟਨਲ 1194 ਫੜੀ ਬੈਠਾ ਹੈ ਅਜਿਹਾ ਵਿਕਰੇਤਾ ਬੰਡਲ ਆਸ ਕਰੋ। ਸਾਕਟ ਦਾ ਮਾਲਕ ss -lunp ਵਿੱਚ ਦਿਸਦਾ ਹੈ; ਯੂਨਿਟ ਜ਼ਿੰਮੇਵਾਰ ਹੈ ਕਿ ਨਹੀਂ ਇਹ ਜਾਣਨ ਲਈ ਉਹ PID systemctl status ਨੂੰ ਦਿਓ। ਸਿਗਨਲ ਨਾਲ ਨਹੀਂ, ਉਸ ਦੇ ਆਪਣੇ ਕੰਟਰੋਲ ਮਾਰਗ ਰਾਹੀਂ ਉਸ ਨੂੰ ਹੇਠਾਂ ਉਤਾਰੋ।

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

ਪਰਜ ਤੋਂ ਬਾਅਦ ਬਚੇ ਯੂਨਿਟ

ਪਰਜ ਬਾਈਨਰੀਆਂ ਹਟਾ ਦਿੰਦਾ ਹੈ; ਹੱਥੀਂ ਲਿਖੀਆਂ ਯੂਨਿਟ ਫਾਈਲਾਂ, ਆਮ ਤੌਰ ’ਤੇ /etc/systemd/system ਹੇਠ, ਉਸ ਤੋਂ ਬਚ ਜਾਂਦੀਆਂ ਹਨ। ਫਿਰ Systemd ਉਸ ਯੂਨਿਟ ਨੂੰ ਮੁੜ ਅਜ਼ਮਾਉਂਦਾ ਹੈ ਜੋ ਹੁਣ ਮੌਜੂਦ ਨਾ ਰਹੇ ਪਾਥ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਸੁਨੇਹਾ ਕੱਲ੍ਹ ਦੀ ਹਟਾਉਣ ਬਾਰੇ ਨਹੀਂ, ਉਸੇ ਗੁੰਮ ਫਾਈਲ ਬਾਰੇ ਹੁੰਦਾ ਹੈ। systemctl status ਯੂਨਿਟ ਦਾ ਫਰੈਗਮੈਂਟ ਪਾਥ ਉੱਪਰ ਵੱਲ ਦਿਖਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਕੁਝ ਵੀ ਹਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਨੂੰ dpkg -S ਨਾਲ ਜਾਂਚੋ। ਅਨਾਥ ਦੇ ਜਾਣ ਮਗਰੋਂ systemctl daemon-reload ਅਤੇ systemctl reset-failed ਹਾਲਤ ਸਾਫ਼ ਕਰਦੇ ਹਨ; ਨਹੀਂ ਤਾਂ ਹਰ ਪਿਛਲੀ ਸਥਿਤੀ-ਜਾਂਚ ਉਸ ਨੂੰ ਵਿਰਾਸਤ ਵਿੱਚ ਪਾਉਂਦੀ ਹੈ।

ਜਦੋਂ which openvpn /usr/local ਹੇਠ ਕੁਝ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਵਰਤੀ ਜਾ ਰਹੀ ਬਾਈਨਰੀ apt ਤੋਂ ਨਹੀਂ, ਵਿਕਰੇਤਾ ਇੰਸਟਾਲਰ ਤੋਂ ਆਈ ਹੈ। ਅਜਿਹਾ ਇੰਸਟਾਲਰ ਆਮ ਤੌਰ ’ਤੇ ਆਪਣਾ ਸਰੋਤਾ, ਆਪਣੀ ਬੂਟ ਐਂਟਰੀ ਅਤੇ ਆਪਣੀ ਕਾਨਫਿਗ ਡਾਇਰੈਕਟਰੀ ਲਿਆਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਦਿਸਣ ਵਾਲਾ ਕਮਾਂਡ ਹਟਾਉਣ ਨਾਲ ਸਾਕਟ ਫੜਿਆ ਹੀ ਰਹਿੰਦਾ ਹੈ।

ਵਿਕਰੇਤਾ ਜਿਵੇਂ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ ਉਸੇ ਤਰ੍ਹਾਂ ਅਣਇੰਸਟਾਲ ਕਰੋ, ss -lunp ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪੋਰਟ ਖਾਲੀ ਹੈ, ਅਤੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਹੀ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਕਲਾਇੰਟ ਸ਼ਾਮਲ ਕਰੋ।

ਮੁੜ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਪਹਿਲਾਂ ਹਾਲਤ ਠੀਕ ਕਰੋ

ਇਸ ਤੋਂ ਸਿੱਟੇ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਫੇਲ੍ਹ ਹਾਲਤ ਸਾਫ਼ ਕਰੋ: systemctl reset-failed ਕਾਊਂਟਰ ਹਟਾਉਂਦਾ ਹੈ, ਅਤੇ ਫਿਰ systemctl status ਯੂਨਿਟ ਦਾ ਇਤਿਹਾਸ ਨਹੀਂ, ਉਸ ਦੀ ਮੌਜੂਦਾ ਹਾਲਤ ਦੱਸਦਾ ਹੈ। ਇਸ ਨੂੰ ਇੱਕ ਵਾਰ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਮਸ਼ੀਨ ਦੀ ਸਮੁੱਚੀ ਹਾਲਤ ਨਹੀਂ, ਉਸੇ ਰਨ ਦਾ ਆਪਣਾ ਜਰਨਲ ਪੜ੍ਹੋ। ਟਨਲ ਕੁਝ ਨਾ ਢੋਂਦਿਆਂ ਵੀ ਸਰਗਰਮ ਦੱਸਣ ਵਾਲਾ ਯੂਨਿਟ ਵੱਖਰੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਕਿਤੇ ਵੱਧ ਆਮ। ਦੋਵੇਂ ਬੱਗ ਰਿਪੋਰਟਾਂ ਵਿੱਚ ਰਲ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਦੋਵੇਂ ਵਰਤੋਂਕਾਰ ਦੇ «VPN ਕੰਮ ਨਹੀਂ ਕਰਦਾ» ਕਹਿਣ ’ਤੇ ਖ਼ਤਮ ਹੁੰਦੇ ਹਨ।

ਤੁਸੀਂ ਚੁਣੀ ਸ਼ਾਖਾ ਨੋਟ ਕਰੋ: ਪੋਰਟ ਟਕਰਾਅ, ਗੁੰਮ ਬਾਈਨਰੀ, ਗੁੰਮ ਕਾਨਫਿਗ। ਅਗਲੀ ਵਾਰ ਪਛਾਣਨਾ ਤੇਜ਼ ਹੋਵੇਗਾ।