ਪੋਰਟ 1194 ਪਹਿਲਾਂ ਹੀ ਵਰਤੋਂ ਵਿੱਚ ਹੈ: ਇਹ OpenVPN ਸਾਕਟ ਕਿਸਦਾ ਹੈ?

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

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

ਸਹੀ ਬਾਈਂਡ ਗਲਤੀ ਪੜ੍ਹੋ

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

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

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

ਸਾਕਟ ਦੀ ਸੂਚੀ ਬਣਾਓ, ਪੋਰਟ ਦੀ ਨਹੀਂ

ਪੋਰਟ ਨੰਬਰ ਅਧੂਰੀ ਸੂਚੀ ਹੈ। ਅੰਤ ਬਿੰਦੂ ਇੱਕ ਟ੍ਰਾਂਸਪੋਰਟ, ਇੱਕ ਪਤਾ ਪਰਿਵਾਰ, ਇੱਕ ਸਥਾਨਕ ਪਤਾ ਅਤੇ ਇੱਕ ਪੋਰਟ ਹੈ, ਸਭ ਇੱਕੋ ਨੈੱਟਵਰਕ ਨਾਮਸਪੇਸ ਦੇ ਅੰਦਰ। ਇੱਕੋ ਨੰਬਰ ’ਤੇ UDP ਸਰੋਤਾ ਅਤੇ TCP ਸਰੋਤਾ ਵੱਖਰੇ ਸਾਕਟ ਹਨ ਅਤੇ ਵੱਖਰੇ ਨਾਮਸਪੇਸਾਂ ਵਿੱਚ ਇੱਕੋ ਨੰਬਰ ’ਤੇ ਦੋ ਪ੍ਰਕਿਰਿਆਵਾਂ ਕਦੇ ਨਹੀਂ ਮਿਲਦੀਆਂ।

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

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

ਪਤਾ ਕਰੋ ਕਿ ਕਿਹੜੀ ਪ੍ਰਕਿਰਿਆ ਇਸਦੀ ਮਾਲਕ ਹੈ

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

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

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

ਇੱਕ ਮਾਲਕ, ਜਾਂ ਦੋ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਇੰਸਟੈਂਸ

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

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

ਤਿੰਨ ਸ਼ਾਰਟਕੱਟ ਨਾਮ ਦੇਣ ਯੋਗ ਹਨ ਕਿਉਂਕਿ ਇਹ ਇਸ ਗਲਤੀ ਬਾਰੇ ਹਰ ਚਰਚਾ ਵਿੱਚ ਦਿਖਦੇ ਹਨ। ਦੋਸ਼ੀ ਵਰਗਾ ਦਿਖਣ ਵਾਲਾ ਕੋਈ ਵੀ PID ਨਾ ਮਾਰੋ। ਸੁਨੇਹਾ ਚੁੱਪ ਕਰਾਉਣ ਲਈ ਸਾਕਟ ਸਾਂਝ ਬਣਾਉਣਾ ਯੋਗ ਨਾ ਕਰੋ। ਸਰਵਰ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਗਾਹਕ-ਸ਼ੈਲੀ ਦੀ ਅਣਬੱਧ ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਨਾ ਬਦਲੋ ਕਿਉਂਕਿ ਇਸ ਨਾਲ ਬਾਈਂਡ ਗਲਤੀ ਗਾਇਬ ਹੋ ਜਾਂਦੀ ਹੈ; ਸਰਵਰ ਮੂਲ ਟਕਰਾਅ ਨਾਲੋਂ ਨਿਦਾਨ ਕਰਨਾ ਔਖਾ ਢੰਗ ਹੋਣ ਕਰਕੇ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੋ ਜਾਂਦਾ ਹੈ।

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

ਬਾਕੀ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਬਾਈਂਡ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

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