ਸਿਰਫ਼ ਐਨਕ੍ਰਿਪਸ਼ਨ ਹੀ ਦੁਬਾਰਾ ਭੇਜਿਆ ਪੈਕਟ ਕਿਉਂ ਨਹੀਂ ਰੋਕਦਾ

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

ਤੰਤਰ ਛੋਟਾ ਹੈ, ਅਤੇ ਇਸ ਦੇ ਫੇਲ੍ਹ ਹੋਣ ਦੇ ਤਰੀਕੇ ਪੈਕਟ ਨੁਕਸਾਨ ਨਾਲ ਉਲਝਾਉਣੇ ਸੌਖੇ ਹਨ।

ਵੈਧ ਸਾਈਫ਼ਰਟੈਕਸਟ ਤਾਜ਼ਾ ਸਾਈਫ਼ਰਟੈਕਸਟ ਨਹੀਂ

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

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

ਦੁਬਾਰਾ ਭੇਜਣ ਦੇ ਰੱਦ ਹੋਣ ਨੂੰ ਡਿਕ੍ਰਿਪਸ਼ਨ ਫੇਲ੍ਹ ਹੋਣ ਵਜੋਂ ਪੜ੍ਹਨਾ ਤੁਹਾਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਗ਼ਲਤ ਸਬਸਿਸਟਮ ਵੱਲ ਭੇਜਦਾ ਹੈ।

ਕ੍ਰਮ-ਨੰਬਰ ਅਤੇ ਇੱਕ ਵਿੰਡੋ

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

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

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

nstat -az | grep -i XfrmIn
ip -s xfrm state | head -n 30
wg show wg0 transfer

ਸਥਿਤੀ ਕੁੰਜੀ ਦੀ ਹੈ, ਹੋਸਟ ਦੀ ਨਹੀਂ

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

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

ਕੁਝ ਵੀ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਾਰਨ ਦਾ ਨਿਦਾਨ ਕਰੋ

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

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

ਜਾਂਚ ਕੀ ਵਾਅਦਾ ਨਹੀਂ ਕਰਦੀ

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

ਸਮਰਥਿਤ ਸੈਟਿੰਗਾਂ ਨਾਲ ਸੰਭਾਲਿਆ ਸਾਫ਼ਟਵੇਅਰ ਹੀ ਵਰਤੋਂਕਾਰ ਕੋਲ ਉਪਲਬਧ ਵਿਵਹਾਰਕ ਨਿਯੰਤਰਣ ਹੈ। ਪੈਕਟ ਪ੍ਰੋਟੋਕਾਲ ਸੰਭਾਲਦਾ ਹੈ; ਬਾਕੀ ਸਭ ਕਾਰਜਕਾਰੀ ਫ਼ੈਸਲਾ ਰਹਿੰਦਾ ਹੈ।