AH ਜਾਂ ESP? ਪੈਕਟ ਨੂੰ ਕੀ ਬਚਾਉਣਾ ਹੈ, ਉਸ ਤੋਂ ਫੈਸਲਾ ਕਰੋ

ਦੋ IPsec ਪ੍ਰਸਤਾਵ ਇੱਕੋ SHA-ਅਧਾਰਿਤ ਅਖੰਡਤਾ ਐਲਗੋਰਿਦਮ ਦਾ ਨਾਂ ਲੈ ਕੇ ਵੀ ਵੱਖਰੇ ਸੁਰੱਖਿਆ ਪ੍ਰੋਟੋਕੋਲ ਮੰਗ ਸਕਦੇ ਹਨ; AH ਅਤੇ ESP ਇੱਕੋ ਪ੍ਰਮਾਣਿਕਤਾ ਸੈਟਿੰਗ ਦੀਆਂ ਦੋ ਸ਼ਬਦ-ਜੋੜ ਨਹੀਂ ਹਨ। ਪਹਿਲਾਂ ਪ੍ਰੋਟੋਕੋਲ, ਫਿਰ ਉਸ ਦੇ ਐਲਗੋਰਿਦਮ, ਫਿਰ ਉਸ ਦਾ ਮੋਡ ਪੜ੍ਹੋ, ਅਤੇ ਬਹੁਤੀ ਧੁੰਦਲਾਪਨ ਦੂਰ ਹੋ ਜਾਂਦੀ ਹੈ। AH ਪੈਕਟ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ, ਸਫ਼ਰ ਵਿੱਚ ਨਾ ਬਦਲਣ ਵਾਲੇ IP ਹੈਡਰ ਖੇਤਰਾਂ ਸਮੇਤ, ਜਦਕਿ ESP ਆਪਣੇ ਅੰਦਰ ਸਮੇਟੀ ਸਮੱਗਰੀ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਤੇ ਐਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ ਅਤੇ ਬਾਹਰਲਾ ਹੈਡਰ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਇਹੀ ਫ਼ਰਕ ਕਿਸੇ ਵੀ ਹੈਸ਼ ਨਾਂ ਨਾਲੋਂ ਵੱਧ ਤੈਨਾਤੀਆਂ ਤੈਅ ਕਰਦਾ ਹੈ।

AH ਕੀ ਢਕਦਾ ਹੈ ਜੋ ESP ਨਹੀਂ

AH ਅਖੰਡਤਾ, ਡੇਟਾ ਦੇ ਸਰੋਤ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਆਪਣੇ ਤੈਅ ਕੀਤੇ ਦੁਹਰਾਅ-ਰੋਕ ਸੇਵਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਗੋਪਨੀਅਤਾ ਨਹੀਂ। ਇਸ ਦੇ ਘੇਰੇ ਵਿੱਚ ਉੱਪਰਲੀ ਪਰਤ ਦਾ ਡੇਟਾ ਅਤੇ IP ਹੈਡਰ ਦੇ ਉਹ ਖੇਤਰ ਆਉਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇਸ ਦੇ ਨਿਯਮ ਅਟੱਲ ਮੰਨਦੇ ਹਨ, ਭਾਵ ਉਹੀ ਹਿੱਸਾ ਜੋ ESP ਢੋਆ-ਢੁਆਈ ਮੋਡ ਵਿੱਚ ਬਾਹਰ ਛੱਡਦਾ ਹੈ। ਜੇ ਲੋੜ ਕਹੇ ਕਿ IP ਹੈਡਰ ਆਪ ਪ੍ਰਮਾਣਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਉਸ ਦਾ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਪ੍ਰੋਟੋਕੋਲ AH ਹੈ।

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

NAT ਚੋਣ ਨੂੰ ਰੁਕਾਵਟ ਬਣਾ ਦਿੰਦਾ ਹੈ

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

ਹੋਵੇ ਤਾਂ AH ਬਾਹਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਗੱਲ ESP ਤੇ ਉਸ ਦੀ ਐਲਗੋਰਿਦਮ ਚੋਣ ਵੱਲ ਜਾਂਦੀ ਹੈ। ਇਹ ਤਰਜੀਹ ਨਹੀਂ ਰੁਕਾਵਟ ਹੈ, ਇਸ ਲਈ ਇਸ ਦੀ ਥਾਂ ਫੈਸਲੇ ਦੇ ਅੰਤ ਵਿੱਚ ਨਹੀਂ, ਸ਼ੁਰੂ ਵਿੱਚ ਹੈ।

ਮੋਡ ਸਵਾਲ ਨੂੰ ਗੁਣਾ ਕਰਦਾ ਹੈ

ESP ਢੋਆ-ਢੁਆਈ ਮੋਡ ਵਿੱਚ ਉੱਪਰਲੀ ਪਰਤ ਦਾ ਭਾਰ ਬਚਾਉਂਦਾ ਹੈ ਅਤੇ IP ਹੈਡਰ ਛੱਡ ਦਿੰਦਾ ਹੈ; ਸੁਰੰਗ ਮੋਡ ਵਿੱਚ ਅੰਦਰਲਾ IP ਹੈਡਰ ਸਮੇਤ ਪੂਰਾ ਅੰਦਰਲਾ ਪੈਕਟ ਸਮੇਟ ਕੇ ਬਚਾਉਂਦਾ ਹੈ। AH ਕੋਲ ਵੀ ਉਹੀ ਦੋ ਮੋਡ ਹਨ, ਇਸ ਲਈ AH ਜਾਂ ESP ਕੋਈ ਵੀ ਐਲਗੋਰਿਦਮ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲ ਵਿੱਚ ਚਾਰ ਸੰਜੋਗ ਹਨ।

ਸੰਯੁਕਤ ਮੋਡ ਦੇ ESP ਐਲਗੋਰਿਦਮ ਫਿਰ ਦੂਜੇ ਪ੍ਰੋਟੋਕੋਲ ਬਿਨਾਂ ਅਖੰਡਤਾ ਤੈਅ ਕਰਦੇ ਹਨ। AES-GCM ਅਤੇ ChaCha20-Poly1305 ਇੱਕੋ ਬਣਤਰ ਵਿੱਚ ਪ੍ਰਮਾਣਿਕਤਾ ਤੇ ਐਨਕ੍ਰਿਪਸ਼ਨ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਉੱਪਰ AH ਜੋੜਨ ਨਾਲ ਕੁਝ ਨਹੀਂ ਮਿਲਦਾ ਪਰ ਇੱਕ ਹੋਰ ਹੈਡਰ ਤੇ ਇੱਕ ਹੋਰ ਗੱਲਬਾਤ ਖਰਚ ਹੁੰਦੀ ਹੈ। ਢਾਂਚਾ AH ਤੇ ESP ਨੂੰ ਇਕੱਠੇ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਅਮਲੀ ਸਵਾਲ ਇਹ ਹੈ ਕੀ ਤੁਹਾਡਾ ਗੇਟਵੇ ਤੇ ਰਿਲੀਜ਼ ਇਸ ਸੰਜੋਗ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ ਅਤੇ ਕੀ ਬਾਅਦ ਵਿੱਚ ਕੋਈ ਇਸ ਦੀ ਸੰਭਾਲ ਕਰ ਸਕੇਗਾ।

ਸਿਰਫ਼-AH ਲਈ ਇਮਾਨਦਾਰ ਬਦਲ

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

ਪ੍ਰਸਤਾਵ ਵਿੱਚ ESP ਦੇਖਣਾ ਵੀ ਐਨਕ੍ਰਿਪਸ਼ਨ ਦਾ ਸਬੂਤ ਨਹੀਂ। ਐਨਕ੍ਰਿਪਸ਼ਨ ਐਲਗੋਰਿਦਮ ਪੜ੍ਹੋ: NULL ਐਂਟਰੀ ਦਾ ਅਰਥ ਸਿਰਫ਼ ਅਖੰਡਤਾ, ਅਤੇ ਸੰਯੁਕਤ-ਮੋਡ ਐਂਟਰੀ ਦਾ ਅਰਥ ਦੋਵੇਂ।

ਤਿੰਨ ਸਵਾਲਾਂ ਵਿੱਚ ਫੈਸਲਾ ਕਰੋ

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

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

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