DH ਫਾਈਲ ਜਾਂ tls-auth ਕੁੰਜੀ? ਦੋ OpenVPN ਫਾਈਲਾਂ ਵੱਖ ਕਰਨਾ

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

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

ਫਾਈਲ ਦੇ ਨਾਮ ਤੋਂ ਪਹਿਲਾਂ ਲੇਬਲ ਪੜ੍ਹੋ

ਫਾਈਲ ਦੀ ਪਹਿਲੀ ਲਾਈਨ ਨਾਮ ਨਾਲੋਂ ਵੱਧ ਜਾਣਕਾਰੀ ਦਿੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਨਾਮ ਮਨੁੱਖੀ ਰਿਵਾਜ ਹੈ ਅਤੇ ਲੇਬਲ ਔਜ਼ਾਰ ਬਣਾਉਂਦਾ ਹੈ। Diffie-Hellman ਪੈਰਾਮੀਟਰ BEGIN DH PARAMETERS ਦਾ PEM ਲੇਬਲ ਰੱਖਦੇ ਹਨ। OpenVPN ਦੀ ਸਥਿਰ ਕੁੰਜੀ ਬਿਲਕੁਲ ਵੱਖਰੀ ਬਣਤਰ ਹੈ, ਜਿਸਦਾ ਆਪਣਾ ਹੈਡਰ ਅਤੇ ਹੈਕਸ ਪੇਲੋਡ ਹੈ।

ਨਾਮ ਬਦਲਣ ਨਾਲ ਕੁਝ ਵੀ ਬਦਲਦਾ ਨਹੀਂ। ta.key ਨਾਮ ਦੀ ਪੈਰਾਮੀਟਰ ਫਾਈਲ ਅਜੇ ਵੀ ਪੈਰਾਮੀਟਰ ਹੈ, ਅਤੇ dh.pem ਨਾਮ ਦੀ ਸਥਿਰ ਕੁੰਜੀ ਅਜੇ ਵੀ ਸਥਿਰ ਕੁੰਜੀ ਹੈ; ਪਾਰਸਰ ਸਮੱਗਰੀ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਅਸੰਗਤੀ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ। ਪ੍ਰੋਫਾਈਲ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ:

head -n 1 dh.pem
head -n 1 ta.key

ਕਿਹੜੀ ਫਾਈਲ ਚਾਹੀਦੀ ਹੈ ਇਹ ਤੈਅ ਕਰਨ ਵਾਲੀਆਂ ਤਿੰਨ ਸ਼ਰਤਾਂ

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

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

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

ਹਰ ਭੂਮਿਕਾ ਲਈ ਸਹੀ ਸਮੱਗਰੀ ਬਣਾਓ

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

openvpn --genkey tls-auth ta.key

ਉਹ ਕਮਾਂਡ ਨਵੀਂ ਗੁਪਤ ਸਮੱਗਰੀ ਬਣਾਉਂਦੀ ਹੈ; ਇਹ ਮੌਜੂਦਾ ਕੁੰਜੀ ਦੀ ਮੁਰੰਮਤ ਜਾਂ ਜਾਂਚ ਨਹੀਂ ਕਰਦੀ, ਅਤੇ ਦੁਬਾਰਾ ਚਲਾਉਣ ਨਾਲ ਤੁਹਾਨੂੰ ਹੋਰ ਧਿਰਾਂ ਕੋਲ ਨਾ ਹੋਣ ਵਾਲੀ ਵੱਖਰੀ ਕੁੰਜੀ ਮਿਲਦੀ ਹੈ। ਨਤੀਜਾ ਫਾਈਲ ਨੂੰ ਲੋੜ ਵਾਲੀਆਂ ਧਿਰਾਂ ਕੋਲ ਕਿਸੇ ਵੀ ਸਾਂਝੇ ਭੇਦ ਲਈ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਚੈਨਲ ਰਾਹੀਂ ਨਕਲ ਕਰੋ, ਅਤੇ ਦਿਸ਼ਾ ਦਾ ਰਿਵਾਜ ਇਕਸਾਰ ਰੱਖੋ: tls-auth ਨਾਲ ਇੱਕ ਧਿਰ key-direction 0 ਅਤੇ ਦੂਜੀ key-direction 1 ਵਰਤਦੀ ਹੈ।

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

dh none ਦਾ ਕੀ ਅਰਥ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

dh none ਸੰਕੁਚਿਤ ਅਰਥ ਵਾਲੀ ਅਸਲੀ ਹਦਾਇਤ ਹੈ: ਕੋਈ ਵੀ ਸੀਮਿਤ-ਖੇਤਰ ਪੈਰਾਮੀਟਰ ਫਾਈਲ ਲੋਡ ਨਹੀਂ ਹੋਵੇਗੀ, ਕਿਉਂਕਿ ਹੱਥ-ਮਿਲਾਉਣ ਅੰਡਾਕਾਰ ਵਕਰ ਦੀ Diffie-Hellman ਵਰਤਦੀ ਹੈ। ਇਹ ਕੁਝ ਵੀ ਕਮਜ਼ੋਰ ਕਰਨ ਦੇ ਅਰਥ ਵਿੱਚ “DH ਕਦਮ ਛੱਡੋ” ਦਾ ਸੰਖੇਪ ਨਹੀਂ, ਅਤੇ ਇਹ OpenVPN ਨੂੰ ਕੋਈ ਹੋਰ ਫਾਈਲ ਬਦਲ ਵਜੋਂ ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਨਿਸ਼ਚਿਤ ਤੌਰ 'ਤੇ ਨਹੀਂ ਕਹਿੰਦੀ।

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

ਜੇ ਗਲਤ ਫਾਈਲ ਪਹਿਲਾਂ ਹੀ ਤੈਨਾਤ ਹੋ ਚੁੱਕੀ ਹੈ

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

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

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