openssl rand tls-crypt ਦੀ ਲੋੜੀਂਦੀ ਕੁੰਜੀ ਕਿਉਂ ਨਹੀਂ ਬਣਾ ਸਕਦਾ

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

ਡਿਸਕ ਉੱਤੇ ਪਈ ਫ਼ਾਈਲ ਅਸਲ ਵਿੱਚ ਕੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ

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

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

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

ਇੱਕ ਬਣਾਉਣ ਦਾ ਸਮਰਥਿਤ ਤਰੀਕਾ

ਸਾਧਾਰਨ ਸਟੈਟਿਕ ਕੁੰਜੀ ਉਸ ਸਾਧਨ ਨਾਲ ਬਣਾਓ ਜੋ ਇਸ ਨੂੰ ਵਰਤੇਗਾ, ਫਿਰ ਦੋਵਾਂ ਸਿਰਿਆਂ ਤੋਂ ਇਸ ਦਾ ਹਵਾਲਾ ਦਿਓ:

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

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

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

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

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

ਹੱਥ ਨਾਲ ਬਣੇ ਬਾਈਟ ਕਿੱਥੇ ਟੁੱਟਦੇ ਹਨ

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

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

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

ਸਭ ਨੂੰ ਬਾਹਰ ਤਾਲਾ ਲਾਏ ਬਿਨਾਂ ਘੁਮਾਉਣਾ

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

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

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