OpenVPN ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਕੁੰਜੀ ਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕਰਦਾ ਹੈ: ਇਨਲਾਈਨ PEM ਜਾਂ ਫਾਈਲ ਪਾਥ

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

ਦੋ ਭੰਡਾਰਨ ਰੂਪ, ਇੱਕ ਨਿਰਦੇਸ਼

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

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

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

ਇਨਲਾਈਨ ਬਲਾਕ ਆਬਜੈਕਟ ਕਿਵੇਂ ਬਣਦਾ ਹੈ

ਇਨਲਾਈਨ ਸਮੱਗਰੀ ਕਨਫਿਗਰੇਸ਼ਨ ਤੋਂ ਕੱਢੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਟੈਕਸਟ ਵਜੋਂ PEM ਪਾਰਸਰ ਨੂੰ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਉਹ ਪਾਰਸਰ ਆਮ ਹੱਦਾਂ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ: BEGIN ਲਾਈਨ, base64 ਪੇਲੋਡ ਅਤੇ ਮਿਲਦੀ END ਲਾਈਨ। ਜੇ ਬਲਾਕ ਅਸਫਲ ਕਾਪੀ ਕਾਰਨ ਕੱਟਿਆ ਗਿਆ, ਡਾਊਨਲੋਡ ਪੇਜ ਨੇ ਉਸ ਨੂੰ HTML ਵਿੱਚ ਲਪੇਟਿਆ, ਜਾਂ ਡੈਸ਼ ਸਧਾਰਨ ਕਰਨ ਵਾਲੇ ਐਡੀਟਰ ਵਿੱਚ ਖੋਲ੍ਹਿਆ ਗਿਆ, ਤਾਂ ਪਾਰਸਰ ਮੌਜੂਦ ਦਿਖਣ ਵਾਲੀ ਸਮੱਗਰੀ ਤੇ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ।

<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

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

ਜਾਂਚੋ ਕਿ ਲੋਡ ਕੀਤਾ ਪ੍ਰੋਫਾਈਲ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਰੂਪ ਵਰਤਦਾ ਹੈ, ਨਾ ਕਿ ਤੁਹਾਡੇ ਐਡੀਟਰ ਨੇ ਸੰਜੋਗ ਨਾਲ ਕਿਹੜੀ ਫਾਈਲ ਖੋਲ੍ਹੀ:

grep -nE '^(ca|cert|key) |^<(ca|cert|key)>' client.ovpn

ਪਾਥ ਹਵਾਲਾ ਕਿਵੇਂ ਹੱਲ ਹੁੰਦਾ ਹੈ

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

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

ਵੱਖਰੇ ਤੌਰ ਤੇ ਸੰਭਾਲੇ ਸਰਟੀਫਿਕੇਟ ਲਈ, ਉਸ ਦੇ ਉੱਤੇ ਕੁਝ ਵੀ ਡੀਬੱਗ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਫਲਾਈਨ ਪਾਰਸ ਆਬਜੈਕਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ:

openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -check

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

ਪਾਰਸਰ ਗਲਤੀ ਕੀ ਦੱਸ ਸਕਦੀ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

ਪਾਰਸ ਅਸਫਲਤਾ ਸਮੱਸਿਆ ਨੂੰ ਇੱਕ ਇਨਪੁਟ ਅਤੇ ਇੱਕ ਪੜਾਅ ਤੱਕ ਸੀਮਤ ਕਰਦੀ ਹੈ। ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਕਲਾਇੰਟ ਨੇ ਦੋ ਭੰਡਾਰਨ ਰੂਪਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਵਰਤਿਆ, ਅਤੇ ਇਹ ਵੀ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਆਬਜੈਕਟ ਸਵੀਕਾਰ ਹੁੰਦਾ। ਇਹ ਵੱਖਰੇ ਸਬੂਤਾਂ ਵਾਲੇ ਵੱਖਰੇ ਸਵਾਲ ਹਨ।

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

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