tls-auth key-direction: 0 ਅਤੇ 1 ਵੱਖਰੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਮਿਲਦੇ ਨਹੀਂ
tls-auth ਨਾਲ ਦੋਵੇਂ ਸਿਰਿਆਂ ਨੂੰ ਉਲਟ ਦਿਸ਼ਾਵਾਂ ਚਾਹੀਦੀਆਂ ਹਨ, 0 ਅਤੇ 1, ਜਾਂ ਦੋਵੇਂ ਸੈਟਿੰਗ ਛੱਡ ਦੇਣ। ਉਹੀ ਸੰਖਿਆ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਅਤੇ tls-crypt ਇਸਨੂੰ ਕਦੇ ਨਹੀਂ ਵਰਤਦਾ।
ਸੁਰੰਗ ਦਾ ਇੱਕ ਸਿਰਾ ਕੰਟਰੋਲ ਚੈਨਲ ਨੂੰ ਉਸ ਕੁੰਜੀ ਸਲਾਟ ਨਾਲ ਸਾਈਨ ਕਰਦਾ ਹੈ ਜਿਸਨੂੰ ਦੂਜਾ ਸਿਰਾ ਕਦੇ ਨਹੀਂ ਜਾਂਚਦਾ, ਅਤੇ ਇੱਕ ਵੀ ਸਰਟੀਫਿਕੇਟ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਕਨੈਕਸ਼ਨ ਪ੍ਰਮਾਣੀਕਰਨ ਗਲਤੀ ਨਾਲ ਮਰ ਜਾਂਦਾ ਹੈ। tls-auth ਦੀ ਦਿਸ਼ਾ ਅਸੰਗਤੀ ਇਸ ਤਰ੍ਹਾਂ ਦਿਸਦੀ ਹੈ, ਅਤੇ ਇਹ ਨਿਰਧਾਰਕ ਹੈ: ਉਹੀ ਦੋ ਫਾਈਲਾਂ ਹਰ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ, ਹਰ ਨੈੱਟਵਰਕ ਤੋਂ ਫੇਲ੍ਹ ਹੁੰਦੀਆਂ ਹਨ। ਲੌਗ ਵਿੱਚ ਤੁਹਾਡੇ ਵੱਲੋਂ ਲੱਭੇ ਜਾ ਰਹੇ ਵਿਕਲਪ ਦਾ ਨਾਮ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਲੋਕ ਕਦੇ ਨਾ ਟੁੱਟੀਆਂ ਕੁੰਜੀਆਂ ਦੁਬਾਰਾ ਬਣਾਉਂਦੇ ਹਨ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਦੁਬਾਰਾ ਜਾਰੀ ਕਰਦੇ ਹਨ। ਹੱਲ ਇਹ ਹੈ ਕਿ ਦੋਵੇਂ ਸਿਰਿਆਂ ਨੂੰ ਪੂਰਕ ਬਣਾਇਆ ਜਾਵੇ, ਜਾਂ ਦੋਵੇਂ ਨੂੰ ਦੁਇ-ਦਿਸ਼ੀ ਰਹਿਣ ਦਿੱਤਾ ਜਾਵੇ, ਪ੍ਰਮਾਣਿਕਤਾ ਕਮਜ਼ੋਰ ਕਰਨਾ ਨਹੀਂ।
ਫੇਲ੍ਹ ਸਰਟੀਫਿਕੇਟਾਂ ਤੋਂ ਪਹਿਲਾਂ ਆਉਂਦੀ ਹੈ
tls-auth ਨਾਲ ਦੋਵੇਂ ਸਾਥੀ ਇੱਕੋ ਸਾਂਝੀ ਕੁੰਜੀ ਰੱਖਦੇ ਹਨ ਅਤੇ ਹਰ ਇੱਕ ਉਸ ਤੋਂ ਬਣੇ ਦੋ ਸਲਾਟਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਰਤਦਾ ਹੈ: ਇੱਕ ਸਲਾਟ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਕੰਟਰੋਲ ਪੈਕਟ 'ਤੇ ਸਾਈਨ ਕਰਦਾ ਹੈ, ਦੂਜਾ ਆਉਣ ਵਾਲੇ ਪੈਕਟ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਦਿਸ਼ਾ 0 ਅਤੇ ਦਿਸ਼ਾ 1 ਇਹ ਭੂਮਿਕਾਵਾਂ ਉਲਟੇ ਕ੍ਰਮ ਵਿੱਚ ਦਿੰਦੀਆਂ ਹਨ, ਇਸ ਲਈ HMAC ਜਾਂਚਾਂ ਦੇ ਮਿਲਣ ਲਈ ਜੋੜੀ ਪੂਰਕ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਜਦੋਂ ਇੱਕ ਸਿਰੇ 'ਤੇ ਨਿਯੁਕਤੀ ਉਲਟ ਜਾਂਦੀ ਹੈ, ਪ੍ਰਾਪਤਕਰਤਾ ਗਲਤ ਸਲਾਟ ਵਿੱਚ ਦਸਤਖਤ ਲੱਭਦਾ ਹੈ ਅਤੇ ਪੈਕਟ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ। ਸੈਸ਼ਨ ਉੱਥੇ ਹੀ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਗਲਤੀ ਪੈਕਟ ਪ੍ਰਮਾਣੀਕਰਨ ਦੀ ਹੈ, ਸਰਟੀਫਿਕੇਟ ਸਟੋਰ ਜੋ ਬਣਾਉਂਦਾ ਉਸ ਦੀ ਨਹੀਂ।
ਨਿਰਧਾਰਕਤਾ ਨਿਦਾਨ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ਸਮੇਂ ਜਾਂ ਰਾਹ ਦੀ ਸਮੱਸਿਆ ਵੱਖਰਾ ਨਿਸ਼ਾਨ ਛੱਡਦੀ ਹੈ: ਰੁਕ-ਰੁਕ ਕੇ ਕਟੌਤੀ, ਇੱਕ ਦਿਸ਼ਾ ਦੀ ਫੇਲ੍ਹ, ਜਾਂ ਸਿਰਫ਼ ਖਾਸ ਨੈੱਟਵਰਕ 'ਤੇ ਮਰਨ ਵਾਲਾ ਸੈਸ਼ਨ। ਦਿਸ਼ਾ ਅਸੰਗਤੀ ਹਰ ਵਾਰ ਪਹਿਲੇ ਹੈਂਡਸ਼ੇਕ ਵਿੱਚ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਉਹੀ ਦੋ ਫਾਈਲਾਂ ਵਾਲੀ ਦੂਜੀ ਮਸ਼ੀਨ 'ਤੇ ਵੀ ਉਸੇ ਤਰ੍ਹਾਂ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ। --verb 4 'ਤੇ ਲੌਗ ਪੜ੍ਹੋ ਅਤੇ ਆਖਰੀ ਲਾਈਨ ਦੀ ਥਾਂ ਪਹਿਲਾ ਰੱਦ ਕੀਤਾ ਪੈਕਟ ਲੱਭੋ। ਜੇ ਉਹ ਰੱਦ ਕਰਨਾ ਕਿਸੇ ਵੀ ਸਰਟੀਫਿਕੇਟ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਸਾਂਝੀ ਕੁੰਜੀ ਅਤੇ ਉਸਦੀ ਦਿਸ਼ਾ ਜਾਂਚਣ ਯੋਗ ਦੋ ਚੀਜ਼ਾਂ ਹਨ।
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
ਸੰਖਿਆ ਕਿੱਥੇ ਰਹਿੰਦੀ ਹੈ
OpenVPN 2.6 ਦਸਤਾਵੇਜ਼ ਦਿਸ਼ਾ ਲਈ ਦੋ ਥਾਵਾਂ ਦਰਜ ਕਰਦਾ ਹੈ: ਕੁੰਜੀ ਵੱਖਰੀ ਫਾਈਲ ਵਿੱਚ ਹੋਣ 'ਤੇ tls-auth ਦਾ ਦੂਜਾ ਆਰਗੂਮੈਂਟ, ਅਤੇ ਕੁੰਜੀ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਇਨਲਾਈਨ ਹੋਣ 'ਤੇ ਵੱਖਰੀ key-direction ਲਾਈਨ। ਦੋਵੇਂ ਇੱਕੋ ਮੁੱਲ ਸੈੱਟ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਇੱਕ ਰੂਪ ਜਾਂ ਦੂਜਾ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਦੇ ਵੀ ਦੋਵੇਂ ਨਹੀਂ। ਛੱਡਣਾ ਵੀ ਇੱਕ ਚੋਣ ਹੈ, ਅਤੇ ਇਹ ਦੋਵੇਂ ਸਾਥੀਆਂ ਨੂੰ ਦੁਇ-ਦਿਸ਼ੀ ਬੰਦੋਬਸਤ ਵਿੱਚ ਰੱਖਦਾ ਹੈ ਜੋ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਕੋਈ ਵੀ ਧਿਰ ਦਿਸ਼ਾ ਨਹੀਂ ਦੱਸਦੀ। ਇੱਕੋ ਸੰਖਿਆ ਵਾਲੇ ਦੋ ਸਾਥੀ ਉਸ ਬੰਦੋਬਸਤ ਵਿੱਚ ਨਹੀਂ ਹਨ: ਹਰ ਇੱਕ ਇੱਕ ਸਲਾਟ ਵਿੱਚ ਸਾਈਨ ਅਤੇ ਦੂਜੇ ਵਿੱਚ ਜਾਂਚ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਇਹ ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ ਕਰਦੇ ਹਨ।
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
ਇਨਲਾਈਨ ਰੂਪ ਆਪਣੀ ਲਾਈਨ 'ਤੇ ਨਿਰਦੇਸ਼ ਹੈ, ਕੁੰਜੀ ਬਲਾਕ ਦੇ ਖੁੱਲ੍ਹਣ ਵਾਲੇ ਟੈਗ 'ਤੇ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ, ਅਤੇ ਉਸ ਟੈਗ ਵਿੱਚ ਆਰਗੂਮੈਂਟ ਜੋੜਨਾ ਗਲਤੀ ਹੈ, ਦਿਸ਼ਾ ਬਦਲਾਅ ਨਹੀਂ। ਥਾਂ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਨਿਰਦੇਸ਼ ਉਸ ਬਲਾਕ ਤੋਂ ਬਾਹਰ ਹੁੰਦਾ ਹੈ ਜਿਸਦਾ ਉਹ ਹੈ, ਇਸ ਲਈ ਬਲਾਕ ਦੇ ਅੰਦਰ ਲਿਖਿਆ ਮੁੱਲ ਕੁੰਜੀ ਸਮੱਗਰੀ ਵਜੋਂ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ। ਪ੍ਰੋਫਾਈਲ ਦੇ ਵੰਡਣ ਵਾਲੇ ਦੀ ਇੱਛਤ ਬੰਦੋਬਸਤ ਦੀ ਨਕਲ ਕਰੋ, ਜੋੜੀ ਘੜਨ ਦੀ ਥਾਂ, ਕਿਉਂਕਿ ਇੱਕ ਸਰਵਰ ਵਿਰੁੱਧ ਕੰਮ ਕਰਨ ਵਾਲਾ ਪ੍ਰੋਫਾਈਲ ਸ਼ਾਇਦ ਦੂਜੇ ਪਾਸੇ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰਤੀਬਿੰਬਿਤ ਹੋਵੇ।
ਵਿਕਲਪ ਕੀ ਅਛੂਤਾ ਛੱਡਦਾ ਹੈ
ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਟ੍ਰੈਫਿਕ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਨਹੀਂ ਕਰਦਾ। tls-auth ਕੰਟਰੋਲ ਚੈਨਲ ਦੇ ਪੈਕਟਾਂ ਦੁਆਲੇ HMAC ਲਗਾਉਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਡੇਟਾ ਚੈਨਲ ਹੈਂਡਸ਼ੇਕ ਦੌਰਾਨ ਤੈਅ ਸੈਸ਼ਨ ਕੁੰਜੀਆਂ ਨਾਲ ਸੁਰੱਖਿਅਤ ਰਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਥ੍ਰੂਪੁਟ ਜਾਂ ਸਾਈਫਰ ਦਾ ਸਵਾਲ ਦਿਸ਼ਾ-ਸੰਖਿਆ ਨਾਲ ਕੋਈ ਸੰਬੰਧ ਨਹੀਂ ਰੱਖਦਾ। ਸੈਟਿੰਗ ਦੂਜੀ ਐਨਕ੍ਰਿਪਸ਼ਨ ਪਰਤ ਵੀ ਨਹੀਂ ਜੋੜਦੀ, ਅਤੇ ਇਹੀ ਧਾਰਨਾ ਲੋਕਾਂ ਨੂੰ ਲੰਮੀ ਕੁੰਜੀ ਲੱਭਣ ਭੇਜਦੀ ਹੈ।
ਇਹ tls-crypt 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ, ਆਪਣੇ ਵਿਕਲਪਾਂ ਅਤੇ ਕੁੰਜੀ-ਸੰਭਾਲ ਵਾਲਾ ਦੂਜਾ ਕੰਟਰੋਲ ਚੈਨਲ ਤੰਤਰ, ਅਤੇ ਇਹ ਕਿਸੇ ਵੀ ਸਾਥੀ ਦੀ ਸਰਟੀਫਿਕੇਟ ਪਛਾਣ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਇਸ ਲਈ ਕੰਮ ਕਰਨ ਵਾਲੀ ਦਿਸ਼ਾ-ਸਮਾਨਤਾ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਦੋਵੇਂ ਸਿਰੇ ਕੰਟਰੋਲ ਚੈਨਲ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਹੈ 'ਤੇ ਸਹਿਮਤ ਹਨ, ਇਹ ਨਹੀਂ ਕਿ ਭਰੋਸਾ-ਜ਼ੰਜੀਰ ਪ੍ਰਮਾਣਿਤ ਹੋਈ।
ਜੋੜੀ ਨੂੰ ਸਿੱਧਾ ਕਰੋ, ਫਿਰ ਦੁਬਾਰਾ ਜੁੜੋ
ਕਿਸੇ ਵੀ ਇੱਕ ਨੂੰ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਸੰਰਚਨਾਵਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਕਿਉਂਕਿ ਪਹਿਲਾਂ ਹੀ ਸਹੀ ਧਿਰ ਨੂੰ ਸੋਧਣਾ ਕੰਮ ਦੁੱਗਣਾ ਕਰਦਾ ਹੈ। ਹੇਠਾਂ ਦਿੱਤਾ grep ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਹਰ ਫਾਈਲ ਕਿਹੜਾ ਤੰਤਰ ਚੁਣਦੀ ਹੈ; ਵਿਸਥਾਰਤ ਰਨ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕੰਟਰੋਲ ਚੈਨਲ ਪ੍ਰਮਾਣਿਤ ਹੋਇਆ ਜਾਂ ਨਹੀਂ। ਦੋਵੇਂ ਆਉਟਪੁੱਟ ਰੱਖੋ, ਤਾਂ ਜੋ ਅਗਲਾ ਬਦਲਾਅ ਜਾਣੀ-ਪਛਾਣੀ ਸਥਿਤੀ ਨਾਲ ਤੁਲਨਾ ਕੀਤਾ ਜਾ ਸਕੇ।
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
ਕਿਸੇ ਵੀ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਦੋਵੇਂ ਸਾਥੀ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰੋ, ਕਿਉਂਕਿ ਇਹ ਵਿਕਲਪ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਇੱਕ ਵਾਰ ਪੜ੍ਹੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਇੱਕ ਧਿਰ ਨੂੰ ਦੁਬਾਰਾ ਲੋਡ ਕਰਨ ਨਾਲ ਪੁਰਾਣੇ ਸੈਸ਼ਨ ਦੀ ਪੂਰੀ ਉਮਰ ਜੋੜੀ ਅਸੰਗਤ ਰਹਿੰਦੀ ਹੈ। ਜੇ ਤੈਨਾਤੀ ਇਸ ਵੇਲੇ ਦਿਸ਼ਾ ਸੰਰਚਿਤ ਕੀਤੇ ਬਿਨਾਂ ਕੰਮ ਕਰ ਰਹੀ ਹੈ, ਤਾਂ ਇੱਕ ਸਾਥੀ 'ਤੇ ਸੈਟਿੰਗ ਜੋੜਨ ਨਾਲ ਉਹੀ ਫੇਲ੍ਹ ਦੁਬਾਰਾ ਬਣਦੀ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਸ਼ੁਰੂ ਕੀਤਾ ਸੀ; ਜਾਂ ਤਾਂ ਦੋਵੇਂ ਰਹਿਣ ਦਿਓ ਜਾਂ ਦੋਵੇਂ ਸੰਰਚਿਤ ਕਰੋ। ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਸਿਰਾ ਬਦਲੋ ਅਤੇ ਪਿਛਲੀ ਫਾਈਲ ਰੱਖੋ, ਤਾਂ ਜੋ ਰਿਗ੍ਰੈਸ਼ਨ ਮੁੜ-ਨਿਰਮਾਣ ਨਹੀਂ, ਦੋ ਮਿੰਟ ਦਾ ਵਾਪਸੀ ਹੋਵੇ।
ਹਰ ਸਿਰੇ ਲਈ ਤੰਤਰ, ਕੁੰਜੀ ਫਾਈਲ ਅਤੇ ਦਿਸ਼ਾ ਤੈਨਾਤੀ ਨੋਟਾਂ ਵਿੱਚ ਦਰਜ ਕਰੋ, ਨਹੀਂ ਤਾਂ ਅਗਲਾ ਵਿਅਕਤੀ ਦੋ ਸਮਾਨ ਫਾਈਲਾਂ ਪੜ੍ਹ ਕੇ ਮੰਨ ਲਵੇਗਾ ਕਿ ਸੰਖਿਆਵਾਂ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਮਿਲਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਦਿਸ਼ਾ ਤਾਲਮੇਲ ਦੀ ਵਿਸਥਾਰ-ਵਿਵਰਣ ਹੈ, ਸੁਰੱਖਿਆ ਸੁਧਾਰ ਨਹੀਂ: ਇਹ ਕੰਟਰੋਲ ਚੈਨਲ ਦੀਆਂ ਦੋ ਦਿਸ਼ਾਵਾਂ ਨੂੰ ਵੱਖ ਕਰਦੀ ਹੈ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ ਕਰਦੀ।