OpenVPN ਰੀਪਲੇ ਬੈਕਟ੍ਰੈਕ ਲੌਗ ਵਿੱਚ: ਲਾਈਨ ਕੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ

ਲਾਈਨ ਕਹਿੰਦੀ ਹੈ PID_ERR replay-window backtrack occurred, ਅਤੇ ਸਾਰੇ ਖੋਜ ਨਤੀਜੇ ਇਸਨੂੰ ਸੁੱਟੇ ਗਏ ਪੈਕਟ ਅਤੇ ਟੁੱਟੀ ਸੁਰੰਗ ਵਜੋਂ ਸਮਝਾਉਂਦੇ ਹਨ। Community OpenVPN 2.6 ਦੇ UDP ਰਾਹ ਵਿੱਚ, ਉਹ ਸੰਦੇਸ਼ ਉਦੋਂ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਪ੍ਰਾਪਤੀ ਫੰਕਸ਼ਨ ਅਜੇ ਤੈਅ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ ਕਿ ਪੈਕਟ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ। ਇਹ ਨਵਾਂ ਵੱਧ ਤੋਂ ਵੱਧ ਬੈਕਟ੍ਰੈਕ ਦਰਜ ਕਰਦੀ ਹੈ, ਫਿਰ ਉਹੀ ਫੰਕਸ਼ਨ ਸਵੀਕਾਰ ਜਾਂ ਰੱਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੂਰੀ ਦੀ ਤੁਲਨਾ ਵਿੰਡੋ ਅਤੇ ਦਰਜ ਹਾਲਤ ਨਾਲ ਕਰਦਾ ਹੈ। ਲੌਗ ਲੇਬਲ ਨੂੰ ਫੈਸਲਾ ਮੰਨ ਕੇ ਪੜ੍ਹਨਾ ਉਹ ਗਲਤੀ ਹੈ ਜਿਸਨੂੰ ਰੋਕਣ ਲਈ ਇਹ ਜਾਂਚ ਸੂਚੀ ਹੈ।

ਪਹਿਲਾ ਪੜਾਅ: ਪਛਾਣੋ ਕਿ ਲਾਈਨ ਕੀ ਹੈ

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

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

ਦੂਜਾ ਪੜਾਅ: ਉਸ ਪੈਕਟ ਦਾ ਨਤੀਜਾ ਲੱਭੋ

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

journalctl -u openvpn-server@server --since "-10 min" | grep -n -A3 -B3 "backtrack occurred"

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

ਤੀਜਾ ਪੜਾਅ: ਤੈਅ ਕਰੋ ਕਿ ਮੁੜ-ਕ੍ਰਮਬੱਧ ਕਰਨਾ ਅਸਲੀ ਹੈ ਜਾਂ ਨਹੀਂ

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

ਮੁੜ ਜੁੜਨ ਵੇਲੇ ਕੁਝ ਸੰਦੇਸ਼ ਆਮ ਗੱਲ ਹਨ। ਅਸਲੀ ਐਪ ਟਾਈਮਆਊਟ ਦੇ ਨਾਲ ਲਗਾਤਾਰ ਵਹਾਅ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਅਤੇ ਉਹ ਸੰਜੋਗ ਲੇਬਲ ਨਹੀਂ, ਸਬੂਤ ਹੈ।

ਚੌਥਾ ਪੜਾਅ: ਵਿੰਡੋ ਪੈਰਾਮੀਟਰ, ਅਤੇ ਉਹ ਕੀ ਨਹੀਂ ਹਨ

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

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

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

mute 20
replay-window 64 15

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

ਪੰਜਵਾਂ ਪੜਾਅ: ਉਹ ਰਾਹ ਜਾਂਚੋ ਜੋ ਵਰਤੋਂਕਾਰ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ

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

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

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