auth ਡਾਇਜੈਸਟ ਕਿਹੜੇ OpenVPN ਪੈਕਟਾਂ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ?
auth ਵਿਕਲਪ ਪ੍ਰੋਫਾਈਲ ਦੇ ਸੰਕੇਤ ਨਾਲੋਂ ਘੱਟ ਕਵਰ ਕਰਦਾ ਹੈ। ਡਾਇਜੈਸਟ ਨੀਤੀ ਤੈਅ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚੈਨਲ, AEAD ਸਥਿਤੀ ਅਤੇ ਕੰਟਰੋਲ-ਚੈਨਲ ਸੁਰੱਖਿਆ ਦੀ ਜਾਂਚ ਕਰੋ।
OpenVPN ਡਾਇਜੈਸਟ ਬਾਰੇ ਬਹੁਤੀਆਂ ਬਹਿਸਾਂ ਗਲਤ ਪੈਕਟ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ। auth SHA256 ਨੂੰ “ਸਿਰਫ਼ ਉਹੀ ਪੀਅਰ ਸਵੀਕਾਰ ਕਰੋ ਜੋ SHA256 ਦਿੰਦੇ ਹਨ” ਵਜੋਂ ਪੜ੍ਹਨਾ ਪਹਿਲੀ ਗੱਲ ਹੈ ਜੋ ਭੁੱਲਣੀ ਚਾਹੀਦੀ ਹੈ। ਵਿਕਲਪ ਕੁਝ ਖਾਸ ਪੈਕਟਾਂ ਲਈ ਡਾਇਜੈਸਟ ਦਾ ਨਾਂ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਉਹ ਪੈਕਟ ਕਿਹੜੇ ਹਨ ਇਹ ਚੈਨਲ ਉੱਤੇ ਅਤੇ ਇਸ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਉਹ ਚੈਨਲ AEAD ਹੈ ਜਾਂ ਨਹੀਂ। ਹੇਠਾਂ ਦਿੱਤੇ ਚਾਰ ਸਵਾਲ ਕ੍ਰਮ ਵਿੱਚ ਲਓ; ਹਰ ਇੱਕ ਇਹ ਸੀਮਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡੀ ਤੈਨਾਤੀ ਵਿੱਚ ਇਹ ਸੈਟਿੰਗ ਕੀ ਅਰਥ ਰੱਖ ਸਕਦੀ ਹੈ।
ਉਸ ਚੈਨਲ ਦਾ ਨਾਂ ਦਿਓ ਜਿਸਦੀ ਰੱਖਿਆ ਸੈਟਿੰਗ ਨੇ ਕਰਨੀ ਹੈ
OpenVPN ਵਿੱਚ ਇੱਕ ਕੰਟਰੋਲ ਚੈਨਲ ਹੈ ਜੋ TLS ਹੱਥ ਮਿਲਾਉਣ ਟ੍ਰੈਫਿਕ ਢੋਂਦਾ ਹੈ ਅਤੇ ਇੱਕ ਡੇਟਾ ਚੈਨਲ ਹੈ ਜੋ ਟਨਲ ਦਾ ਪੇਲੋਡ ਢੋਂਦਾ ਹੈ। auth ਡਾਇਜੈਸਟ ਦੋਵਾਂ ਵਿੱਚ ਭੂਮਿਕਾ ਨਿਭਾਉਂਦਾ ਹੈ, ਪਰ ਇੱਕੋ ਜਿਹੀ ਨਹੀਂ, ਅਤੇ ਪ੍ਰੋਫਾਈਲ ਫ਼ਰਕ ਨੂੰ ਘੱਟ ਹੀ ਦਿਸਣਯੋਗ ਬਣਾਉਂਦੀ ਹੈ। ਕਾਨਫਿਗ ਫਾਈਲ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਸ ਨੂੰ ਸੀਮਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।
ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ ਇਸ ਗੱਲ ਦਾ ਸੰਖੇਪ ਰੂਪ ਹੈ ਕਿ ਉਹੀ ਵਿਕਲਪ ਹਰ ਸੰਦਰਭ ਵਿੱਚ ਕਿਵੇਂ ਪਹੁੰਚਦਾ ਹੈ।
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
ਇਸ ਉੱਤੇ ਨਿਰਭਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ ਕਿ ਡੇਟਾ ਚੈਨਲ AEAD ਹੈ ਜਾਂ ਨਹੀਂ
ਜੇਕਰ ਗੱਲਬਾਤ ਨਾਲ ਤੈਅ ਡੇਟਾ ਸਾਈਫਰ AES-GCM ਜਾਂ CHACHA20-POLY1305 ਹੈ, ਤਾਂ ਡੇਟਾ ਚੈਨਲ ਆਪਣੇ ਆਪ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਵੱਖਰਾ ਡਾਇਜੈਸਟ ਉਹ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਜੋ ਤੁਸੀਂ ਸ਼ਾਇਦ ਸੋਚ ਰਹੇ ਹੋ। ਦੋਵੇਂ AEAD ਬਣਤਰਾਂ ਹਨ, ਇਸ ਲਈ ਅਖੰਡਤਾ ਉਸੇ ਕਾਰਵਾਈ ਤੋਂ ਬਣਦੀ ਹੈ ਜੋ ਪੇਲੋਡ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰਦੀ ਹੈ। ਇਹ ਕੋਈ ਘਟਾਓ ਨਹੀਂ, ਪਰ ਇਸਦਾ ਅਰਥ ਹੈ ਕਿ “ਹਰ ਡੇਟਾ ਪੈਕਟ HMAC-SHA256 ਹੈ” ਵਜੋਂ ਜਾਇਜ਼ ਠਹਿਰਾਈ ਨੀਤੀ ਉਸ ਟਨਲ ਉੱਤੇ ਤੱਥਾਤਮਕ ਤੌਰ ’ਤੇ ਗਲਤ ਹੈ। ਨੀਤੀ ਦੁਬਾਰਾ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰਵਰ ਲਾਗ ਜਾਂ ਕਲਾਇੰਟ ਸਥਿਤੀ ਆਉਟਪੁੱਟ ਵਿੱਚ ਤੈਅ ਮੁੱਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
ਪ੍ਰੋਫਾਈਲ ਦੀ ਸੂਚੀ ਦੀ ਬਜਾਏ ਅਸਲ ਵਿੱਚ ਤੈਅ ਹੋਇਆ ਸਾਈਫਰ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਗੱਲਬਾਤ ਸਮੂਹ ਦੇ ਕਿਸੇ ਹੋਰ ਮੈਂਬਰ ਉੱਤੇ ਆ ਸਕਦੀ ਹੈ। data-ciphers AES-256-GCM:AES-128-GCM ਇੱਕ ਗੱਲਬਾਤ ਸੂਚੀ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਐਂਟਰੀਆਂ AEAD ਹਨ, ਇਸ ਲਈ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਪੇਲੋਡ ਸੁਰੱਖਿਆ ਲਈ auth ਡਾਇਜੈਸਟ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦਾ।
ਕੰਟਰੋਲ-ਚੈਨਲ ਸੁਰੱਖਿਆ ਨੂੰ ਵੱਖਰਾ ਫ਼ੈਸਲਾ ਮੰਨੋ
tls-auth ਕੰਟਰੋਲ-ਚੈਨਲ ਪੈਕਟਾਂ ਵਿੱਚ HMAC ਜੋੜਦਾ ਹੈ ਅਤੇ ਆਪਣਾ ਡਾਇਜੈਸਟ auth ਸੈਟਿੰਗ ਤੋਂ ਲੈਂਦਾ ਹੈ, ਇਸ ਲਈ AEAD ਟਨਲ ਵਿੱਚ ਵੀ ਅਰਥਪੂਰਨ ਡਾਇਜੈਸਟ ਕਾਨਫਿਗਰ ਹੋ ਸਕਦਾ ਹੈ। tls-crypt ਆਪਣੀ ਨਿਸ਼ਚਿਤ ਸੁਰੱਖਿਆ ਵਾਲੀ ਵੱਖਰੀ ਵਿਵਸਥਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਇਹ tls-auth ਦਾ ਹਰ ਗੁਣ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦਾ ਹੈ। ਧਾਰਨਾਵਾਂ ਨੂੰ ਇੱਕ-ਦੂਜੇ ਉੱਤੇ ਤਬਦੀਲ ਕਰਨ ਦੀ ਬਜਾਏ ਚੁਣੀ ਹੋਈ ਵਿਧੀ ਦੀ ਦਸਤਾਵੇਜ਼ੀ ਜਾਣਕਾਰੀ ਪੜ੍ਹੋ।
ਦੋਵੇਂ ਪੀਅਰਾਂ ਨੂੰ ਵਿਵਸਥਾ ਅਤੇ ਕੁੰਜੀ ਦੀ ਦਿਸ਼ਾ ਉੱਤੇ ਵੀ ਸਹਿਮਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਮੇਲ ਖਾਂਦਾ ਡਾਇਜੈਸਟ ਪਰ ਗਲਤ ਦਿਸ਼ਾ ਵਿੱਚ ਵਰਤੀ ਗਈ ਕੁੰਜੀ ਫਾਈਲ ਅਜਿਹਾ ਹੱਥ ਮਿਲਾਉਣ ਬਣਾਉਂਦੀ ਹੈ ਜੋ ਅਜਿਹੇ ਕਾਰਨਾਂ ਕਰਕੇ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਜੋ ਡਾਇਜੈਸਟ ਸੈਟਿੰਗ ਸਮਝਾ ਨਹੀਂ ਸਕਦੀ।
auth ਨੂੰ ਸਾਈਫਰ ਗੱਲਬਾਤ ਅਤੇ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਤੋਂ ਵੱਖਰਾ ਰੱਖੋ
ਤਿੰਨ ਸੈਟਿੰਗਾਂ ਲਗਾਤਾਰ ਮਿਲਾ ਦਿੱਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ: auth ਡਾਇਜੈਸਟ, ਡੇਟਾ-ਸਾਈਫਰ ਸੂਚੀ ਅਤੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਦਾ ਦਸਤਖ਼ਤ ਐਲਗੋਰਿਦਮ। ਪਹਿਲੀ ਬਦਲਣ ਨਾਲ ਪ੍ਰਮਾਣ ਪੱਤਰ ਦੁਬਾਰਾ ਜਾਰੀ ਨਹੀਂ ਹੁੰਦਾ, ਉਸਦਾ ਦਸਤਖ਼ਤ ਡਾਇਜੈਸਟ ਚੁਣਿਆ ਨਹੀਂ ਜਾਂਦਾ, ਅਤੇ ਉਪਭੋਗਤਾ-ਪਾਸਵਰਡ ਢੰਗ ਨਹੀਂ ਬਣਦਾ। ਪ੍ਰੋਟੋਕਾਲ ਵਿਕਲਪਾਂ ਦੀਆਂ ਪਰਿਭਾਸ਼ਾਵਾਂ OpenVPN 2.6 ਸਰੋਤਾਂ ਵਿੱਚ ਹਰ ਇੱਕ ਨੂੰ ਆਪਣੇ ਭਾਗ ਵਿੱਚ ਬਿਆਨ ਕਰਦੀਆਂ ਹਨ, ਜੋ ਇਹ ਯਾਦ ਰੱਖਣ ਲਈ ਲਾਹੇਵੰਦ ਹੈ ਕਿ ਇਹ ਸੁਤੰਤਰ ਨੌਬ ਹਨ।
ਡਾਇਜੈਸਟ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਜੇ ਪੀਅਰ ਜੁੜਨ ਤੋਂ ਇਨਕਾਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਕਾਰਨ ਆਮ ਤੌਰ ’ਤੇ ਬਾਕੀ ਦੋ ਸੈਟਿੰਗਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਅਸੰਗਤੀ ਹੁੰਦਾ ਹੈ। ਕੋਈ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਸਿਰੇ ਪੜ੍ਹੋ।
ਨੀਤੀ ਲਿਖੋ ਅਤੇ ਚੱਲ ਰਹੇ ਕਾਨਫਿਗਾਂ ਨਾਲ ਤੁਲਨਾ ਕਰੋ
ਫਲੀਟ-ਪੱਧਰੀ ਬਿਆਨ ਵਿੱਚ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਡੇਟਾ-ਚੈਨਲ ਮੋਡ ਅਤੇ ਚੁਣੀ ਹੋਈ ਕੰਟਰੋਲ-ਚੈਨਲ ਸੁਰੱਖਿਆ ਦਾ ਸਪਸ਼ਟ ਜ਼ਿਕਰ ਇੱਕ ਹੀ ਵਾਕ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਹ ਵਾਕ ਪਰਖਣਯੋਗ ਹੈ; “ਅਸੀਂ SHA256 ਵਰਤਦੇ ਹਾਂ” ਨਹੀਂ। ਫਿਰ ਇਸਦੀ ਤੁਲਨਾ ਪ੍ਰਭਾਵੀ ਸਰਵਰ ਅਤੇ ਕਲਾਇੰਟ ਪ੍ਰੋਫਾਈਲਾਂ ਨਾਲ ਕਰੋ, ਰਿਪੋਜ਼ਟਰੀ ਦੇ ਟੈਂਪਲੇਟ ਨਾਲ ਨਹੀਂ।
ਹਰ ਟਨਲ ਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਤੈਅ ਕੀਤਾ ਅਤੇ ਕਿਹੜੀ ਵਿਧੀ ਨੇ ਉਸਦੇ ਪੈਕਟ ਪ੍ਰਮਾਣਿਤ ਕੀਤੇ, ਇਹ ਦਰਜ ਕਰਕੇ ਸਮਾਪਤ ਕਰੋ। ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਦਿਸਣ ਵਾਲੀ auth ਲਾਈਨ ਸਿਰਫ਼ ਕਾਨਫਿਗਰੇਸ਼ਨ ਦੇ ਇਰਾਦੇ ਦਾ ਸਬੂਤ ਹੈ, ਅਤੇ ਇਰਾਦਾ ਜਾਂਚ ਦਾ ਸਭ ਤੋਂ ਸਸਤਾ ਹਿੱਸਾ ਹੈ।