OpenVPN ਕੰਟਰੋਲ ਪੈਕਟਾਂ ਦਾ ਪਤਾ ਲਗਾਉਣਾ: TLS ਤੋਂ ਪਹਿਲਾਂ tls-auth

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

ਲਿਫ਼ਾਫ਼ੇ ਨੂੰ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਪੜ੍ਹੋ ਜਿਸ ਵਿੱਚ ਇਹ ਬਣਦਾ ਹੈ

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

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

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

ਦਿਖਾਓ ਕਿ ਜਾਂਚ ਹੈਂਡਸ਼ੇਕ ਤੋਂ ਪਹਿਲਾਂ ਚੱਲਦੀ ਹੈ

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

ਡੈਮਨ ਦੀ ਵਰਬੋਸਿਟੀ ਵਧਾਓ ਅਤੇ tun ਡਿਵਾਈਸ ਦੀ ਥਾਂ ਕੰਟਰੋਲ ਚੈਨਲ ਵੇਖੋ:

openvpn --config /etc/openvpn/server.conf --verb 6

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

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

ਦੋਵੇਂ ਸਿਰਿਆਂ ’ਤੇ ਕੁੰਜੀ, ਦਿਸ਼ਾ ਅਤੇ digest ਮਿਲਾਓ

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

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

ਸਾਂਝਾ ਭੇਤ ਸੰਪਾਦਕ ਦੀ ਥਾਂ ਸੰਦ ਨਾਲ ਬਣਾਓ, ਅਤੇ ਇਜਾਜ਼ਤਾਂ ਕੱਸੀਆਂ ਰੱਖੋ:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

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

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

ਟੈਗ ਸਿਰਫ਼ ਅਸਲ ਫਾਰਮੈਟ ਤੋਂ ਦੁਬਾਰਾ ਬਣਾਓ

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

ਟੈਗ ਦੀ ਲੰਬਾਈ digest ਤੋਂ ਆਉਂਦੀ ਹੈ, ਇਸ ਲਈ ਸਥਿਰ ਲੰਬਾਈ ਦੀ ਧਾਰਨਾ ਉਸੇ ਪਲ ਟੁੱਟ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਕੋਈ ਇਸਨੂੰ ਬਦਲਦਾ ਹੈ। ਪੈਕਟ ਨੂੰ ਅਮਲ ਵਾਂਗ ਹੈਸ਼ ਕਰੋ, ਬਲੌਗ ਪੋਸਟ ਦੀ ਸਾਰਣੀ ਵਾਂਗ ਪੇਸ਼ ਨਹੀਂ, ਅਤੇ ਹੱਥ ਨਾਲ ਕੱਢੀ ਉਮੀਦ ਨਾਲ ਨਹੀਂ, ਉਸੇ ਸਾਥੀ ਤੋਂ ਲਏ ਕੈਪਚਰ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।

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

ਸੁਰੱਖਿਆ ਹਟਾਏ ਬਿਨਾਂ ਅਸਹਿਮਤੀ ਵਾਪਸ ਲਓ

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

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

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