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

ਜੋ ਸ਼ੈੱਲ ਕੰਮ ਕਰਦਾ ਹੈ ਉਸ ਵਿੱਚ command -v openvpn ਜਵਾਬ ਛਾਪਦਾ ਹੈ, ਅਤੇ ਇਹ ਅਕਸਰ /usr/sbin/openvpn ਹੁੰਦਾ ਹੈ, ਭਾਵ ਅਜਿਹੀ ਡਾਇਰੈਕਟਰੀ ਜਿਸਨੂੰ cron ਆਪਣੇ ਖੋਜ ਪਾਥ ਵਿੱਚ ਨਹੀਂ ਰੱਖਦਾ।

ਟਨਲ ਕਦੇ ਸ਼ੁਰੂ ਹੀ ਨਹੀਂ ਹੋਇਆ, ਇਸ ਲਈ ਟਨਲ ਸਮੱਸਿਆ ਨਹੀਂ

cron ਵੱਲੋਂ ਸ਼ੁਰੂ ਕੀਤੇ ਕੰਮ ਘੱਟੋ-ਘੱਟ ਵਾਤਾਵਰਨ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦੇ ਹਨ, ਆਮ ਤੌਰ ’ਤੇ PATH=/usr/bin:/bin, ਅਤੇ ਕੋਈ ਨਿਯੰਤਰਕ ਟਰਮੀਨਲ ਨਹੀਂ ਲੈਂਦੇ। /usr/sbin ਜਾਂ /usr/local/sbin ਵਿੱਚ ਸਥਾਪਿਤ ਕੋਈ ਵੀ ਚੀਜ਼ ਉਸ ਸੂਚੀ ਵਿੱਚ ਸਿੱਧੀ ਗੈਰਹਾਜ਼ਰ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਲਾਗ ਦੀ ਲਾਈਨ TLS ਗਲਤੀ ਦੀ ਥਾਂ openvpn: not found ਪੜ੍ਹਦੀ ਹੈ। Python ਦਾ subprocess ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ: ਇਹ ਇੰਟਰਪ੍ਰਿਟਰ ਪ੍ਰਕਿਰਿਆ ਦਾ ਵਾਤਾਵਰਨ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦਾ ਹੈ, ਜੋ cron ਨਾਲੋਂ ਅਮੀਰ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਟਿਲਡਾ ਫੈਲਾਉਣ ਲਈ ਅਜੇ ਵੀ ਕੋਈ ਸ਼ੈੱਲ ਨਹੀਂ। ਦੋਵੇਂ ਫੇਲ੍ਹਤਾਵਾਂ ਇੱਕ ਵੀ ਪੈਕੇਟ ਮੇਜ਼ਬਾਨ ਛੱਡਣ ਤੋਂ ਪਹਿਲਾਂ ਹੁੰਦੀਆਂ ਹਨ।

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

ਨਿਰਪੇਖ ਪਾਥ ਅਤੇ ਦਲੀਲ ਸੂਚੀਆਂ ਸ਼ੈੱਲ ਸਟਰਿੰਗਾਂ ਨੂੰ ਹਰਾਉਂਦੀਆਂ ਹਨ

ਹੱਲ ਹੋਇਆ ਪਾਥ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਦਿਓ ਅਤੇ ਸ਼ੈੱਲ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੱਡ ਦਿਓ। subprocess.run(["/usr/sbin/openvpn", "--config", config, "--verb", "4"], capture_output=True, text=True, timeout=90) ਤੁਹਾਨੂੰ ਰਿਟਰਨ ਕੋਡ, stdout ਅਤੇ stderr ਦਿੰਦਾ ਹੈ, ਸ਼ੈੱਲ ਨੂੰ ਫਾਈਲਨਾਮ ਦੀ ਵਿਆਖਿਆ ਕਰਨ ਲਈ ਕਹੇ ਬਿਨਾਂ। ਸੰਰਚਨਾ ਦਾ ਪਾਥ os.environ["HOME"] ਜਾਂ pathlib.Path.home() ਤੋਂ ਬਣਾਓ, ਤਾਂ ਜੋ ਟਿਲਡਾ ਕਦੇ ਫੈਲਾਉਣਾ ਨਾ ਪਵੇ। ਜਦੋਂ ਸੱਚਮੁੱਚ ਸ਼ੈੱਲ ਸਿੰਟੈਕਸ ਚਾਹੀਦਾ ਹੋਵੇ, shlex.split ਵਰਤੋ, ਕਿਉਂਕਿ .split() ਨਾਲ ਸਟਰਿੰਗ ਵੰਡਣਾ ਖਾਲੀ ਥਾਂ ਵਾਲੇ ਕਿਸੇ ਵੀ ਪਾਥ ’ਤੇ ਟੁੱਟ ਜਾਂਦਾ ਹੈ। stderr ਵੀ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ OpenVPN ਆਪਣੀਆਂ ਜ਼ਿਆਦਾਤਰ ਸ਼ੁਰੂਆਤੀ ਫੇਲ੍ਹਤਾਵਾਂ ਉੱਥੇ ਹੀ ਲਿਖਦਾ ਹੈ।

ਇਹੀ ਨਿਯਮ cron ’ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਕੰਮ ਦੀ ਲਾਈਨ ਲੌਗਇਨ ਸ਼ੈੱਲ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਕੋਈ ਤੁਹਾਡੀ ਪਰੋਫਾਈਲ ਲੋਡ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਕੋਈ ਤੁਹਾਡੇ ਉਪਨਾਮ ਪਰਿਭਾਸ਼ਿਤ ਨਹੀਂ ਕਰਦਾ।

crontab ਅਸਲ ਵਿੱਚ ਕੀ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦਾ ਹੈ

crontab ਐਂਟਰੀ ਨੂੰ ਉਹ ਵਾਤਾਵਰਨ ਮਿਲਦਾ ਹੈ ਜੋ crontab ਘੋਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਨਾਲ ਕੁਝ ਵਿਰਾਸਤੀ ਡਿਫ਼ਾਲਟ, ਇਸ ਲਈ ਪਾਥ ਪੂਰਾ ਲਿਖੋ ਜਾਂ ਕਾਲ ਨੂੰ ਅਜਿਹੀ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਲਪੇਟੋ ਜੋ ਇਹ ਕਰਦੀ ਹੋਵੇ। ਫਾਈਲ ਦੇ ਸਿਖਰ ’ਤੇ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin ਵਰਗੀ ਲਾਈਨ ਆਮ ਸਥਾਪਨਾ ਥਾਵਾਂ ਨੂੰ ਢਕਦੀ ਹੈ, ਅਤੇ >> cron.log 2>&1 ਨਾਲ ਰੀਡਾਇਰੈਕਟ ਕਰਨਾ ਹੀ ਅਗਲੀ ਫੇਲ੍ਹਤਾ ਨੂੰ ਪੜ੍ਹਨਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਪਾਸਫ੍ਰੇਜ਼ ਨਾਲ ਸੁਰੱਖਿਅਤ ਪਰੋਫਾਈਲ ਕੋਲ cron ਹੇਠ ਆਪਣਾ ਭੇਤ ਮੰਗਣ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ, ਕਿਉਂਕਿ ਪੁੱਛਣ ਲਈ ਕੋਈ ਟਰਮੀਨਲ ਨਹੀਂ। ਅਜਿਹਾ ਕਨੈਕਸ਼ਨ systemd ਇਕਾਈ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਪ੍ਰਮਾਣ ਫਾਈਲ ਪੜ੍ਹ ਸਕੇ, ਅਜਿਹੇ ਕੰਮ ਵਿੱਚ ਨਹੀਂ ਜੋ ਆਪਣੇ ਆਪ ਨੂੰ ਇੰਟਰਐਕਟਿਵ ਦਿਖਾਉਂਦਾ ਹੈ।

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

ਵਾਤਾਵਰਨ ਹਟਾ ਕੇ ਇਹ ਸਾਬਤ ਕਰੋ

ਘੱਟੋ-ਘੱਟ ਵਾਤਾਵਰਨ ਸਿੱਧਾ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰੋ: env -i PATH=/usr/bin:/bin /usr/sbin/openvpn --config office.ovpn --verb 4। ਉਸ ਰਨ ਤੋਂ ਪਾਥ ਜਾਂ ਟਰਮੀਨਲ ਦੀ ਸ਼ਿਕਾਇਤ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਮੱਸਿਆ VPN ਦੇ ਉੱਪਰ ਹੈ। ਜੇ ਇਹ ਜੁੜਦਾ ਹੈ, ਤਾਂ ਬਾਕੀ ਸ਼ੱਕੀ ਹਨ ਉਹ ਖਾਤਾ ਜਿਸ ਹੇਠ ਇਹ ਚੱਲਦਾ ਹੈ, ਉਹ ਡਾਇਰੈਕਟਰੀ ਜਿੱਥੋਂ ਇਹ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਹ ਪ੍ਰਮਾਣ ਜੋ ਇਹ ਪੇਸ਼ ਕਰਦਾ ਹੈ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਨਤੀਜਾ ਸਰਟੀਫਿਕੇਟ ਜਾਂਚ ਦੇ ਇੱਕ ਹੋਰ ਦੌਰ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ।

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

ਇਕਾਈ ਨੂੰ ਸਹੀ ਕ੍ਰਮ ਵੀ ਚਾਹੀਦਾ ਹੈ: Wants=network-online.target ਨਾਲ After=network-online.target ਕਲਾਇੰਟ ਨੂੰ ਪਤਾ ਜਾਂ ਡਿਫ਼ਾਲਟ ਰੂਟ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਰੋਕਦੇ ਹਨ, ਜੋ ਨਹੀਂ ਤਾਂ ਸਰਟੀਫਿਕੇਟ ਜਾਂ TLS ਗਲਤੀਆਂ ਵਜੋਂ ਦਿਸਦਾ ਹੈ ਅਤੇ ਹੱਥੋਂ ਮੁੜ ਚਾਲੂ ਕਰਨ ’ਤੇ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ