ਤੁਹਾਡੀ ਸੁਰੰਗ ਉੱਪਰ ਆਉਂਦੀ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਜੁੜਦਾ ਹੈ, ਪਰ ਸਥਿਰ ਪਤਾ ਅਤੇ ਉਸ ਇੱਕ ਵਰਤੋਂਕਾਰ ਲਈ ਤੁਹਾਡੇ ਦੁਆਰਾ ਤੈਅ ਕੀਤੇ ਧੱਕੇ ਹੋਏ ਰਾਹ ਗੁੰਮ ਹਨ। ਲੌਗ ਵਿੱਚ “file not found” ਨਹੀਂ ਲਿਖਿਆ, ਅਤੇ ਇਹੀ ਲੋਕਾਂ ਨੂੰ ਸਰਟੀਫਿਕੇਟ ਦੁਬਾਰਾ ਬਣਾਉਣ ਭੇਜਦਾ ਹੈ। ਅਜਿਹੇ ਬਹੁਤੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਡੈਮਨ ਤੁਹਾਡੇ ਜਾਂਚੇ ਸ਼ੈਲ ਤੋਂ ਵੱਖਰੀ ਡਾਇਰੈਕਟਰੀ ਤੋਂ ਚੱਲਦਾ ਹੈ, ਅਤੇ client-config-dir ਤੁਹਾਡੇ ਅਨੁਮਾਨ ਅਨੁਸਾਰ ਕਦੇ ਹੱਲ ਨਹੀਂ ਹੋਇਆ। ਸੁਧਾਰ ਰਾਹ ਦਾ ਸੁਧਾਰ ਹੈ, ਪ੍ਰਮਾਣ-ਪੱਤਰ ਰੀਸੈਟ ਕਰਨਾ ਨਹੀਂ।

ਸੰਰਚਨਾ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਯੂਨਿਟ ਪੜ੍ਹੋ

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

systemctl show openvpn-server@server -p ExecStart -p WorkingDirectory -p User -p RootDirectory

ਖਾਲੀ WorkingDirectory ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਯੂਨਿਟ / ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਸਾਪੇਖ client-config-dir ccd /ccd ਵਿੱਚ ਲੱਭਿਆ ਜਾਂਦਾ ਹੈ। ਉਹ ਡਾਇਰੈਕਟਰੀ ਲਗਭਗ ਕਦੇ ਨਹੀਂ ਹੁੰਦੀ, ਅਤੇ ਡੈਮਨ ਉਸ ਦੀ ਗੈਰਹਾਜ਼ਰੀ ਨੂੰ ਘਾਤਕ ਨਹੀਂ ਮੰਨਦਾ।

ਇਸ ਦੀ ਤੁਲਨਾ ਜਾਂਚ ਦੌਰਾਨ ਵਰਤੀ ਇੰਟਰੈਕਟਿਵ ਸ਼ੁਰੂਆਤ ਨਾਲ ਕਰੋ, ਜਿੱਥੇ ਤੁਹਾਡੇ ਸ਼ੈਲ ਦੀ ਮੌਜੂਦਾ ਡਾਇਰੈਕਟਰੀ ਸ਼ਾਇਦ ਸੰਰਚਨਾ ਡਾਇਰੈਕਟਰੀ ਸੀ। ਉਹੀ ਫਾਈਲ, ਉਹੀ ਕੀਵਰਡ, ਦੋ ਵੱਖਰੇ ਨਤੀਜੇ।

ਸਾਪੇਖ ਰਾਹ ਕਿਸ ਦੇ ਸਾਪੇਖ ਹੱਲ ਹੁੰਦਾ ਹੈ

ਕੀਵਰਡ ਉਸ ਪਲ ਪ੍ਰਕਿਰਿਆ ਦੀ ਕੰਮਕਾਰੀ ਡਾਇਰੈਕਟਰੀ ਦੇ ਸਾਪੇਖ ਹੱਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਵਿਕਲਪ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਦਾ ਮਤਲਬ “ਉਸ ਸੰਰਚਨਾ ਫਾਈਲ ਦੇ ਕੋਲ ਜੋ ਮੈਂ --config ਨਾਲ ਭੇਜੀ” ਨਹੀਂ ਹੈ। OpenVPN ਪੂਰਨ ਰਾਹ ਤੋਂ ਸੰਰਚਨਾ ਖੁਸ਼ੀ ਨਾਲ ਪੜ੍ਹੇਗਾ ਅਤੇ ਫਿਰ ਵੀ ਸਾਪੇਖ ਮੁੱਲ ਕਿਤੇ ਹੋਰ ਹੱਲ ਕਰੇਗਾ, ਅਤੇ ਇੱਥੇ ਬਿਲਕੁਲ ਇਹੀ ਜਾਲ ਹੈ। OpenVPN 2.6 ਦਾ ਦਸਤਾਵੇਜ਼ ਨਿਯਮ --client-config-dir ਹੇਠ ਅਤੇ ਦੁਬਾਰਾ --cd ਹੇਠ ਦੱਸਦਾ ਹੈ।

cd ਕੀਵਰਡ ਹੋਰ ਫਾਈਲਾਂ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਸੰਦਰਭ ਬਦਲਦਾ ਹੈ, ਇਸ ਲਈ ਜੋ ਯੂਨਿਟ cd /etc/openvpn/server ਸੈੱਟ ਕਰਦੀ ਹੈ ਅਤੇ ਫਿਰ client-config-dir ccd, ਉਹ /etc/openvpn/server/ccd ਵਿੱਚ ਹੱਲ ਹੁੰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ cd ਜੋੜਦੇ ਹੋ, ਤਾਂ ਨਿਰਦੇਸ਼ਾਂ ਦਾ ਕ੍ਰਮ ਜਾਂਚੋ ਅਤੇ ਯਾਦ ਰੱਖੋ ਕਿ ਇਹ ਉਸੇ ਫਾਈਲ ਦੇ ਹਰ ਹੋਰ ਸਾਪੇਖ ਹਵਾਲੇ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।

ਡੈਮਨ ਦੇ ਖਾਤੇ ਵਜੋਂ ਰਾਹ ਚੱਲੋ

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

namei ਹਰ ਹਿੱਸੇ ਦੀ ਇਜਾਜ਼ਤ ਕ੍ਰਮ ਵਿੱਚ ਛਾਪਦਾ ਹੈ, ਜੋ ਡਾਇਰੈਕਟਰੀਆਂ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਜਾਂਚਣ ਤੋਂ ਤੇਜ਼ ਹੈ:

namei -l /etc/openvpn/server/ccd/client1

ਫਿਰ ਪੜ੍ਹਨ ਨੂੰ ਆਪਣੇ ਆਪ ਵਜੋਂ ਨਹੀਂ, ਸੇਵਾ ਖਾਤੇ ਵਜੋਂ ਪਰਖੋ:

runuser -u openvpn -- test -r /etc/openvpn/server/ccd/client1 && echo readable

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

ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਖੋਜ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

openvpn --config /etc/openvpn/server.conf --verb 4 --client-config-dir /etc/openvpn/server/ccd

ਇਸਨੂੰ ਵਾਧੂ ਪੋਰਟ ਉੱਤੇ ਅਗਲੇ ਭਾਗ ਵਿੱਚ ਚਲਾਓ ਅਤੇ ਇੱਕ ਕਲਾਇੰਟ ਜੋੜੋ। ਇਹ systemd ਨੂੰ ਤਸਵੀਰ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਟਾ ਦਿੰਦਾ ਹੈ: ਜੇ ਓਵਰਰਾਈਡ ਇੱਥੇ ਦਿਖਦੇ ਹਨ ਅਤੇ ਸੇਵਾ ਹੇਠ ਨਹੀਂ, ਤਾਂ ਫ਼ਰਕ ਯੂਨਿਟ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਹੈ, ਫਾਈਲ ਵਿੱਚ ਨਹੀਂ।

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

ਸੁਧਾਰੋ, ਰੀਸਟਾਰਟ ਕਰੋ, ਪੁਸ਼ਟੀ ਕਰੋ

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

client-config-dir /etc/openvpn/server/ccd
ccd-exclusive

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

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

ਸੰਬੰਧਿਤ ਲੇਖ