ਕਿਉਂ nc -uz ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ OpenVPN ਸਰਵਰ ਤਿਆਰ ਹੈ

ਚਲਾਉਣਾ nc -uz ਇੱਕ OpenVPN ਸਰਵਰ ਵਿਰੁੱਧ ਲਗਭਗ ਕੁਝ ਵੀ ਨਹੀਂ ਮਾਪਦਾ, ਅਤੇ OpenBSD ਪੁਸਤਿਕਾ ਆਪਣੀਆਂ ਚੇਤਾਵਨੀਆਂ ਵਿੱਚ ਇਹੀ ਕਹਿੰਦੀ ਹੈ: ਉਸ ਮੋਡ ਵਿੱਚ UDP ਸਕੈਨ ਕੁਝ ਸੁਣ ਰਿਹਾ ਹੋਵੇ ਜਾਂ ਨਾ, ਸਫਲਤਾ ਦੀ ਰਿਪੋਰਟ ਕਰਦੇ ਹਨ। ਐਗਜ਼ਿਟ ਸਥਿਤੀ ਦੂਰ ਦੀ ਸਥਿਤੀ ਨਹੀਂ, ਸਥਾਨਕ ਭੇਜਣ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ, ਇਸ ਲਈ ਇਸ ’ਤੇ ਭਰੋਸਾ ਕਰਨ ਵਾਲਾ ਨਿਗਰਾਨ ਪ੍ਰਕਿਰਿਆ ਸਾਰਣੀ ਭਰੋਸੇਯੋਗ ਦਿਖਣ ਤੱਕ ਮਰੇ ਸਰਵਰ ਨੂੰ ਸਿਹਤਮੰਦ ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਰੱਖਦਾ ਹੈ। ਇਸ ਨੂੰ ਬਦਲਣ ਦੀ ਸ਼ੁਰੂਆਤ ਇਹ ਤੈਅ ਕਰਨ ਤੋਂ ਹੁੰਦੀ ਹੈ ਕਿ ਜਾਂਚ ਨੂੰ ਕਿਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਪ੍ਰਕਿਰਿਆ, ਸਰੋਤਾ, ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਪਹੁੰਚ ਚਾਰ ਵੱਖਰੇ ਨਿਰੀਖਣ ਹਨ। ਜਿਹੜੀ ਜਾਂਚ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ ਉਹ ਲਾਹੇਵੰਦ ਹੈ; ਜਿਹੜੀ ਚਾਰੇ ਦੱਸਦੀ ਹੈ ਉਹ ਬੋਝ ਹੈ।

UDP ਜਾਂਚ ਕੀ ਦੇਖ ਸਕਦੀ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

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

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

ਜਾਂਚ ਨੂੰ ਸੰਰਚਿਤ ਟ੍ਰਾਂਸਪੋਰਟ ਨਾਲ ਮਿਲਾਉਣਾ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਵੀ ਨਤੀਜੇ ’ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਉਂਦਾ ਹੈ। UDP ਤੈਨਾਤੀ ਨੂੰ ਵੱਖਰਾ ਸੰਕੇਤ ਚਾਹੀਦਾ ਹੈ, ਵੱਖਰਾ ਪ੍ਰੋਟੋਕਾਲ ਨਹੀਂ।

ਤਿੰਨ ਕਾਲ ਕਰਨ ਵਾਲੇ, ਤਿੰਨ ਵੱਖਰੇ ਸਵਾਲ

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

ਇਹ ਇੱਕੋ ਜਾਂਚ ਨਹੀਂ ਹੈ, ਅਤੇ ਇੱਕ ਜਾਂਚ ਤਿੰਨੇਂ ਨੂੰ ਇਮਾਨਦਾਰੀ ਨਾਲ ਢਕ ਨਹੀਂ ਸਕਦੀ। ਪਹਿਲਾਂ ਕਾਲ ਕਰਨ ਵਾਲਾ ਚੁਣੋ, ਫਿਰ ਸਬੂਤ।

ਮੌਜੂਦਾ ਇੰਸਟੈਂਸ ਤੋਂ ਜਾਂਚ ਬਣਾਓ

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

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

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

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

ਇਸ ਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਤੋੜੋ ਅਤੇ ਜਾਂਚ ਦੇਖੋ

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

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

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

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

ਸਥਿਤੀ ਲਾਈਨ ਨੂੰ ਕੀ ਕਹਿਣਾ ਚਾਹੀਦਾ ਹੈ

ਦਰਜ ਕਰੋ ਕਿ ਹਰ ਜਾਂਚ ਕਿਹੜੀ ਹੱਦ ਢਕਦੀ ਹੈ: ਪ੍ਰਕਿਰਿਆ, ਸਰੋਤਾ, ਪ੍ਰਮਾਣਿਕਤਾ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ। ਇੱਕ ਜਾਂਚ ਇੱਕ ਤੋਂ ਵੱਧ ਘੱਟ ਹੀ ਢਕਦੀ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ “up” ਵਿੱਚ ਦਬਾਉਣ ਵਾਲਾ ਸਥਿਤੀ ਸਫ਼ਾ ਘਟਨਾ ਦੌਰਾਨ ਮਹੱਤਵਪੂਰਨ ਫ਼ਰਕ ਲੁਕਾਉਂਦਾ ਹੈ। ਨੈੱਟਵਰਕ ਰਾਹ ਲਈ ਸਮਰਪਿਤ ਪਛਾਣ ਵਾਲਾ ਅਸਲ ਕਲਾਇੰਟ ਵਰਤੋ, ਉਸ ਨੂੰ ਹੱਥ ਮਿਲਾਉਣਾ ਅਤੇ ਇੱਕ ਨਿਰਦੋਸ਼ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਕਾਰਵਾਈ ਪੂਰੀ ਕਰਨ ਦਿਓ, ਫਿਰ ਡਿਸਕਨੈਕਟ ਕਰੋ। ਇਹ ਇੱਕੋ ਕਦਮ ਵਿੱਚ ਨਿਯੰਤਰਣ ਚੈਨਲ, ਪ੍ਰਮਾਣਿਕਤਾ ਨੀਤੀ ਅਤੇ ਸਰੋਤੇ ਨੂੰ ਅਭਿਆਸ ਕਰਾਉਂਦਾ ਹੈ।

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

ਚੇਤਾਵਨੀ ਦੇ ਟੈਕਸਟ ਵਿੱਚ ਹੱਦ ਦਾ ਨਾਮ ਲਓ, ਤਾਂ ਜੋ ਪਹਿਲੇ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਨੂੰ ਪਤਾ ਲੱਗੇ ਕਿ ਯੂਨਿਟ, ਸਾਕਟ, ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਰਸਤਾ ਦੇਖਣਾ ਹੈ। ਜੋ ਜਾਂਚ ਦੱਸ ਨਹੀਂ ਸਕਦੀ ਕਿ ਉਸ ਨੇ ਕੀ ਸਾਬਤ ਕੀਤਾ, ਉਸ ’ਤੇ ਗਲਤ ਕਾਰਨ ਨਾਲ ਭਰੋਸਾ ਕੀਤਾ ਜਾਵੇਗਾ, ਅਤੇ netcat ਜਾਂਚ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇਸੇ ਤਰ੍ਹਾਂ ਹੀ ਬਚੀ ਰਹੀ।