ਤੁਹਾਡਾ PiVPN ਪ੍ਰੋਫਾਈਲ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ OpenVPN ਇੰਸਟੈਂਸ ਵਰਤ ਰਿਹਾ ਹੈ?

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

ਹੈਲਪਰ ਅਤੇ ਡੈਮਨ ਵੱਖਰੀਆਂ ਵਸਤੂਆਂ ਹਨ

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

systemd ਹੋਸਟ 'ਤੇ ਡਾਇਰੈਕਟਰੀ ਸੂਚੀ ਦੀ ਬਜਾਏ ਸਰਗਰਮ ਯੂਨਿਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਨਾਮ ਪੈਕੇਜਿੰਗ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ: Debian ਅਤੇ Raspberry Pi OS ਇਮੇਜ ਆਮ ਤੌਰ 'ਤੇ ਟੈਂਪਲੇਟ ਇੰਸਟੈਂਸ ਦਿੰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ openvpn-server@server, ਜਦਕਿ ਪੁਰਾਣੀਆਂ ਇੰਸਟਾਲਾਂ openvpn@server ਵਰਤਦੀਆਂ ਹਨ। ਫਾਈਲ ਨਾਮ ਤੋਂ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦੀ ਬਜਾਏ ਪ੍ਰਬੰਧਕ ਨੂੰ ਪੁੱਛੋ ਕਿ ਕਿਹੜਾ ਚੱਲ ਰਿਹਾ ਹੈ।

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

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

ਡੈਮਨ ਵੱਲੋਂ ਹੱਲ ਕੀਤੀ ਕੌਂਫਿਗਰੇਸ਼ਨ ਚੇਨ ਦਾ ਪਿੱਛਾ ਕਰੋ

OpenVPN ਸੈਟਿੰਗਾਂ ਲਈ ਡਾਇਰੈਕਟਰੀ ਸਕੈਨ ਨਹੀਂ ਕਰਦਾ। ਇਹ --config ਨਾਲ ਦਿੱਤੀ ਫਾਈਲ ਪੜ੍ਹਦਾ ਹੈ, ਅੰਦਰਲੇ ਕਿਸੇ ਵੀ config ਨਿਰਦੇਸ਼ ਦਾ ਪਿੱਛਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਕਮਾਂਡ-ਲਾਈਨ ਵਿਕਲਪ ਲਾਗੂ ਕਰਦਾ ਹੈ। 2.6 ਦਾ ਮੈਨੁਅਲ ਉਸ ਕ੍ਰਮ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਉਦੋਂ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਦੋਂ ਦੋ ਫਾਈਲਾਂ ਪੋਰਟ, ਡਿਵਾਈਸ ਜਾਂ ਸਾਈਫਰ 'ਤੇ ਸਹਿਮਤ ਨਹੀਂ ਹੁੰਦੀਆਂ।

ਪਹਿਲਾਂ ਪ੍ਰਭਾਵੀ ਕਾਲ ਡੰਪ ਕਰੋ, ਫਿਰ ਪਛਾਣ ਅਤੇ ਪਹੁੰਚ ਤੈਅ ਕਰਨ ਵਾਲੇ ਨਿਰਦੇਸ਼ ਵੇਖੋ। ਦੋਵੇਂ ਕਮਾਂਡ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਵਾਲੇ ਹਨ ਅਤੇ ਜੀਵਤ ਸਰਵਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਹਨ, ਹਾਲਾਂਕਿ ਦੂਜਾ ਸਾਂਝੇ ਟਿਕਟ ਵਿੱਚ ਤੁਹਾਨੂੰ ਨਾ ਚਾਹੀਦੇ ਪਾਥ ਛਾਪਦਾ ਹੈ।

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

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

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

ਲੌਗ ਨੂੰ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਮਿਲਾਓ, ਤੁਹਾਨੂੰ ਯਾਦ ਵਾਲੀ ਗਲਤੀ ਨਾਲ ਨਹੀਂ

ਦੋ ਲੌਗ ਟਿਕਾਣੇ ਆਮ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ journal ਹੈ। log-append ਸੈਟ ਹੋਣ 'ਤੇ ਡੈਮਨ ਉਸ ਫਾਈਲ ਵਿੱਚ ਲਿਖਦਾ ਹੈ ਅਤੇ journal ਸਟਾਰਟਅਪ ਲਾਈਨਾਂ ਤੋਂ ਬਿਨਾਂ ਥੋੜ੍ਹਾ ਹੀ ਰੱਖਦਾ ਹੈ। ਇਸ ਤੋਂ ਬਿਨਾਂ journalctl ਘਟਨਾਵਾਂ ਦਾ ਸਰੋਤ ਹੈ।

journalctl -u openvpn-server@server -n 80 --no-pager

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

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

ਆਖਰੀ ਆਮ ਅਸਫਲਤਾ ਦੀ ਬਜਾਏ ਪਹਿਲੀ ਠੋਸ ਅਸਫਲਤਾ ਦਰਜ ਕਰੋ। ਬਾਈਂਡ ਗਲਤੀ, ਬਿਨਾਂ ਜਵਾਬ ਵਾਲਾ ਬਾਹਰੀ ਅਦਲ-ਬਦਲ, ਸਰਟੀਫਿਕੇਟ ਇਨਕਾਰ ਅਤੇ ਖਾਤਾ ਇਨਕਾਰ ਹਰ ਇੱਕ ਤੁਹਾਨੂੰ ਵੱਖਰੀ ਪਰਤ 'ਤੇ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਅੰਤ ਵਾਲਾ ਟਾਈਮਆਉਟ ਅਕਸਰ ਉੱਪਰਲੀ ਲਾਭਦਾਇਕ ਘਟਨਾ ਲੁਕਾ ਦਿੰਦਾ ਹੈ।

ਸੁਰੰਗ ਮੁੜ ਬਣਾਉਣਾ ਨਿਦਾਨ ਦਾ ਕਦਮ ਨਹੀਂ ਹੈ

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

ਇਹੀ ਗੱਲ tls-auth ਜਾਂ tls-crypt ਬੰਦ ਕਰਨ, verify-x509-name ਢਿੱਲਾ ਕਰਨ, ਜਾਂ ਹਰਾ ਦਰਜਾ ਲੈਣ ਲਈ ਦੂਜਾ ਕਾਰਕ ਛੱਡਣ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ। ਜੋ ਸੁਰੰਗ ਜਾਂਚ ਹਟਾਏ ਜਾਣ ਕਾਰਨ ਕਨੈਕਟ ਹੁੰਦੀ ਹੈ ਉਹ ਵੱਖਰੀ ਪ੍ਰਣਾਲੀ ਹੈ, ਮੁਰੰਮਤ ਕੀਤੀ ਨਹੀਂ।

ਲੌਗ ਵੱਲੋਂ ਨਾਮ ਦਿੱਤੀ ਪਰਤ 'ਤੇ ਇੱਕ ਸੀਮਿਤ ਬਦਲਾਅ ਕਰੋ, ਉਹੀ ਯੂਨਿਟ ਰੀਸਟਾਰਟ ਕਰੋ, ਅਤੇ ਉਹੀ ਇੱਕ ਕਨੈਕਸ਼ਨ ਕੋਸ਼ਿਸ਼ ਦੁਹਰਾਓ। ਇਹ ਤੁਲਨਾ ਇਮਾਨਦਾਰ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਵਾਪਸ ਲਿਆ ਜਾ ਸਕਣ ਵਾਲਾ ਬਦਲਾਅ ਛੱਡਦਾ ਹੈ।

ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਕੀ ਦੇਣਾ ਹੈ

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

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

ਜੇ ਚੇਨ ਅਟੁੱਟ ਹੈ ਅਤੇ ਲੌਗ ਅਜੇ ਵੀ ਨੈੱਟਵਰਕ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਅਗਲਾ ਕਦਮ ਕਲਾਇਟ ਅਤੇ ਸਰਵਰ ਵਿਚਕਾਰਲਾ ਰਾਹ ਹੈ, ਦੂਜੀ ਇੰਸਟਾਲ ਨਹੀਂ। ਕਹਾਣੀ ਦਾ ਉਹੀ ਹਿੱਸਾ ਹੈਲਪਰ ਕੋਲ ਕਦੇ ਨਹੀਂ ਸੀ।