keepalive ਮੁੜ ਕਨੈਕਟ ਨਹੀਂ ਹੈ: ਆਪਣੀ ਮੌਜੂਦਾ ਨਾਕਾਮੀ ਦੇ ਆਧਾਰ 'ਤੇ ਚੁਣੋ
ਇੱਕ ਪੈਕੇਟ ਮੈਪਿੰਗ ਨੂੰ ਜੀਵਤ ਰੱਖਦਾ ਹੈ; ਮੁੜ ਕਨੈਕਟ ਸੰਬੰਧ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਂਦਾ ਹੈ। ਕਾਰਜਵਿਧੀ ਨੂੰ ਨਾਕਾਮੀ ਨਾਲ ਮਿਲਾਓ, ਫਿਰ ਅਸਲ ਬੇਨਤੀ ਨਾਲ ਜਾਂਚੋ।
keepalive ਅਤੇ ਮੁੜ ਕਨੈਕਟ ਇੱਕੋ ਸਾਹ ਵਿੱਚ ਸੰਰਚਿਤ ਹੁੰਦੇ ਹਨ ਪਰ ਵੱਖਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਨੂੰ ਟਿਊਨ ਕਰਨਾ ਦੂਜੇ ਨੂੰ ਘੱਟ ਹੀ ਠੀਕ ਕਰਦਾ ਹੈ। keepalive ਥੋੜ੍ਹੀ ਟ੍ਰੈਫਿਕ ਭੇਜ ਕੇ ਸਟੇਟ ਐਂਟਰੀ ਨੂੰ ਜੀਵਤ ਰੱਖਦਾ ਹੈ ਜਾਂ ਇਹ ਨੋਟ ਕਰਦਾ ਹੈ ਕਿ ਸਾਥੀ ਨੇ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੱਤਾ ਹੈ। ਮੁੜ ਕਨੈਕਟ ਟੁੱਟਿਆ ਹੋਇਆ ਢਾਹ ਕੇ ਸੰਬੰਧ ਦੁਬਾਰਾ ਬਣਾਉਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਕੁੰਜੀਆਂ, ਪਤੇ ਅਤੇ ਰੂਟ ਸ਼ਾਮਲ ਹਨ। ਨਾਕਾਮੀ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਕਾਰਜਵਿਧੀ ਚੁਣੋ, ਜਿਸਦਾ ਨੋਬ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੇ ਹੋ ਉਹ ਨਹੀਂ। ਦੋ ਸਵਾਲ ਇਹ ਤੈਅ ਕਰਦੇ ਹਨ: ਕੀ ਰਾਹ ਮਰ ਚੁੱਕਾ ਹੈ, ਜਾਂ ਸਾਥੀਆਂ ਵਿਚਕਾਰ ਕੁਝ ਇਸਨੂੰ ਭੁੱਲ ਰਿਹਾ ਹੈ?
ਜਦੋਂ ਮੈਪਿੰਗ ਹੀ ਸਮੱਸਿਆ ਹੈ
ਕੁਝ ਮਿੰਟਾਂ ਦੀ ਚੁੱਪ ਤੋਂ ਬਾਅਦ ਹੀ ਮਰਨ ਵਾਲਾ ਟਨਲ ਆਮ ਤੌਰ 'ਤੇ ਸਾਥੀ ਨਹੀਂ ਬਲਕਿ ਅਨੁਵਾਦ ਐਂਟਰੀ ਗੁਆਂਦਾ ਹੈ। WireGuard ਦਾ PersistentKeepalive NAT ਅਤੇ ਫਾਇਰਵਾਲ ਸਟੇਟ ਲਈ ਮੌਜੂਦ ਹੈ, ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਦੇ ਆਪਣੇ ਨੋਟ ਇਸਨੂੰ ਬਿਲਕੁਲ ਇਸੇ ਤਰ੍ਹਾਂ ਬਿਆਨ ਕਰਦੇ ਹਨ, ਸਿਹਤ-ਜਾਂਚ ਵਜੋਂ ਨਹੀਂ। ਕੁਝ ਦਹਾਈ ਸਕਿੰਟਾਂ ਦਾ ਅੰਤਰਾਲ ਐਂਟਰੀ ਨੂੰ ਗਰਮ ਰੱਖਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਹਰ ਸਕਿੰਟ ਇੱਕ ਪੈਕੇਟ ਬੈਟਰੀ ਦਾ ਫ਼ੈਸਲਾ ਹੈ, ਭਰੋਸੇਯੋਗਤਾ ਦਾ ਨਹੀਂ। OpenVPN ਉਸੇ ਥਾਂ 'ਤੇ ਪਹੁੰਚਦਾ ਹੈ ping ਅਤੇ ping-restart ਰਾਹੀਂ, ਜੋ ਪਹਿਲਾਂ ਚੁੱਪ ਨੂੰ ਨੋਟ ਕਰਦੇ ਹਨ ਅਤੇ ਫਿਰ ਉਸ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ।
ਇਹ ਸੈਟਿੰਗਾਂ ਪ੍ਰੋਟੋਕੋਲਾਂ ਵਿਚਕਾਰ ਵੀ ਬਦਲੀਆਂ ਨਹੀਂ ਜਾ ਸਕਦੀਆਂ। IKEv2 ਦੀ ਮ੍ਰਿਤ ਸਾਥੀ ਨੀਤੀ, OpenVPN ਦਾ ping ਟਾਈਮਰ ਅਤੇ WireGuard ਦਾ keepalive ਇੱਕੋ ਸਵਾਲ ਦਾ ਜਵਾਬ ਤਿੰਨ ਵੱਖਰੇ ਸਿੰਟੈਕਸ ਅਤੇ ਤਿੰਨ ਵੱਖਰੇ ਡਿਫਾਲਟ ਨਾਲ ਦਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰ ਸੰਖਿਆ ਕਾਪੀ ਕਰਨਾ ਟਿਊਨਿੰਗ ਦੇ ਭੇਸ ਵਿੱਚ ਅੰਦਾਜ਼ਾ ਹੈ।
ਜਦੋਂ ਸੰਬੰਧ ਚਲਾ ਗਿਆ ਹੋਵੇ
ਜੇ ਸਾਥੀ ਪਤਾ ਬਦਲੇ, ਪ੍ਰਮਾਣ-ਪੱਤਰ ਦੀ ਮਿਆਦ ਖ਼ਤਮ ਹੋਵੇ ਜਾਂ ਦੂਰਲਾ ਸਿਰਾ ਮੁੜ ਸ਼ੁਰੂ ਹੋਵੇ, ਤਾਂ ਛੋਟੇ ਪੈਕੇਟ ਮੁਰੰਮਤ ਨਹੀਂ ਹਨ। ਮੁੜ ਕਨੈਕਟ ਨੂੰ ਸਟੇਟ ਦੁਬਾਰਾ ਬਣਾਉਣੀ ਪੈਂਦੀ ਹੈ : ਪਤਾ ਲਵੋ, ਰੂਟ ਦੁਬਾਰਾ ਇੰਸਟਾਲ ਕਰੋ, ਕੁੰਜੀਆਂ ਦੁਬਾਰਾ ਗੱਲਬਾਤ ਕਰੋ ਅਤੇ ਕੁਝ ਡਿਪਲਾਏਮੈਂਟਾਂ ਵਿੱਚ ਵਰਤੋਂਕਾਰ ਨੂੰ ਦੁਬਾਰਾ ਪ੍ਰਮਾਣਿਤ ਕਰੋ।
ਬਿਨਾਂ ਨਿਗਰਾਨੀ ਮੁੜ ਕਨੈਕਟ ਕਰਨ ਵਾਲੇ ਕਲਾਇੰਟ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਜਾਂ ਸੰਭਾਲਿਆ ਭੇਤ ਰੱਖਦੇ ਹਨ। ਮਨੁੱਖ ਨੂੰ ਪੁੱਛਣ ਵਾਲਾ ਕਲਾਇੰਟ ਠੀਕ ਤਦੋਂ ਹੀ ਨਾਕਾਮ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਹਾਜ਼ਰ ਨਹੀਂ, ਅਤੇ ਇਹੀ ਉਹ ਸਥਿਤੀ ਹੈ ਜਿੱਥੇ ਮੁੜ ਕਨੈਕਟ ਦਾ ਮਹੱਤਵ ਸੀ। ਇਹ ਮਹੀਨਿਆਂ ਪਹਿਲਾਂ ਲਿਆ ਗਿਆ ਡਿਜ਼ਾਈਨ ਫ਼ੈਸਲਾ ਹੈ, ਆਊਟੇਜ ਦੌਰਾਨ ਬਦਲਣ ਵਾਲੀ ਸੈਟਿੰਗ ਨਹੀਂ।
ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਕੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ
ਟਨਲ ਮੁੜ ਕਨੈਕਟ ਹੋਇਆ, ਕੁੰਜੀਆਂ ਅਤੇ ਰੂਟਾਂ ਵਾਲਾ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਇਸਦੇ ਪਿੱਛੇ ਦੀ ਸੇਵਾ ਬੰਦ ਹੋਵੇ, ਅਤੇ keepalive ਉਸ ਸੈਸ਼ਨ ਲਈ ਮੈਪਿੰਗ ਖੁੱਲ੍ਹੀ ਰੱਖ ਸਕਦਾ ਹੈ ਜਿਸਦਾ ਸਰਵਰ ਘੰਟੇ ਪਹਿਲਾਂ ਜਾ ਚੁੱਕਾ ਹੈ। ਜੋ ਚੀਜ਼ ਤੁਹਾਡੇ ਲਈ ਸੱਚਮੁੱਚ ਮਹੱਤਵਪੂਰਨ ਹੈ ਉਹ ਉਪਲਬਧ ਨਾ ਹੋਣ 'ਤੇ ਵੀ ਦੋਵੇਂ ਕਾਰਜਵਿਧੀਆਂ ਸਫਲਤਾ ਦੀ ਰਿਪੋਰਟ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਇਸ ਲਈ ਜਾਂਚ ਅਸਲ ਬੇਨਤੀ 'ਤੇ ਖ਼ਤਮ ਹੁੰਦੀ ਹੈ। ਜਿਸ ਅੰਤਰਾਲ ਦੀ ਤੁਹਾਨੂੰ ਪਰਵਾਹ ਹੈ ਉਸ ਤੋਂ ਬਾਅਦ ਟਨਲ ਰਾਹੀਂ ਕੁਝ ਭੇਜੋ, ਫਿਰ ਜਿਸ ਨਾਕਾਮੀ ਲਈ ਤੁਸੀਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਸੀ ਉਸਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਪੈਦਾ ਕਰੋ: ਮੈਪਿੰਗ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਨਿਸ਼ਕਿਰਿਆ ਅਵਧੀ, ਮੁੜ ਕਨੈਕਟ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨਾ ਜਾਂ ਪਤਾ ਬਦਲਣਾ।
ਸਿੱਧੀ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੋਕਣਾ ਵੱਖਰਾ ਫ਼ੈਸਲਾ ਹੈ
ਮੁੜ ਕਨੈਕਟ ਲੂਪ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਿਹਤਮੰਦ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਕੋਈ ਐਪ ਚੁੱਪਚਾਪ ਆਮ ਰਾਹ ਵਰਤ ਰਹੀ ਹੋਵੇ, ਅਤੇ ਇਹ ਨਾਕਾਮੀ ਨਹੀਂ ਬਲਕਿ ਲੀਕ ਹੈ। ਜੇ ਸ਼ਰਤ ਇਹ ਹੈ ਕਿ ਟਨਲ ਤੋਂ ਬਾਹਰ ਕੁਝ ਨਾ ਜਾਵੇ, ਤਾਂ ਕਲਾਇੰਟ ਸੰਰਚਨਾ ਵਿੱਚ ਇਹ ਸਪੱਸ਼ਟ ਕਹੋ ਅਤੇ ਟਨਲ ਹੇਠਾਂ ਉਤਾਰ ਕੇ ਦੇਖੋ ਕਿ ਹਾਲੇ ਵੀ ਕੀ ਜੁੜਦਾ ਹੈ, ਇਸ ਨਾਲ ਸਾਬਤ ਕਰੋ। ਕੋਈ ਵੀ ਕਾਰਜਵਿਧੀ ਇਸ ਵਿਵਹਾਰ ਨੂੰ ਨਹੀਂ ਦਰਸਾਉਂਦੀ, ਅਤੇ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਦਾ ਕੋਈ ਅਨੁਸ਼ਾਸਨ ਇਸਨੂੰ ਸਥਾਪਿਤ ਨਹੀਂ ਕਰਦਾ।
ਕਿਹੜੀ ਕਾਰਜਵਿਧੀ ਚੱਲੀ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਨਵੀਂ ਬੇਨਤੀ ਸਫਲ ਹੋਈ ਜਾਂ ਨਹੀਂ, ਨੋਟ ਕਰੋ। ਅਗਲੇ ਇੰਜੀਨੀਅਰ ਨੂੰ ਇਹੀ ਦੋ ਤੱਥ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਸਟੇਟਸ ਆਈਕਨ ਵਿੱਚ ਨਹੀਂ ਦਿਸਦਾ। ਕਲਾਇੰਟ ਦਾ ਮੁੜ ਕਨੈਕਟ ਹੋਣਾ ਦੱਸਣ ਵਾਲੀ ਲੌਗ ਲਾਈਨ ਉਸ ਬੇਨਤੀ ਵਰਗੀ ਨਹੀਂ ਜੋ ਕੰਮ ਕਰ ਗਈ।
ਨੀਤੀ ਲਿਖੋ, ਸਿਰਫ਼ ਸੰਖਿਆ ਨਹੀਂ
ਜੋੜੀ ਨੂੰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਰੱਖੋ: ਨਿਸ਼ਕਿਰਿਆ ਅੰਤਰਾਲ, ਜੀਵਨ-ਸ਼ਕਤੀ ਦੀ ਸੀਮਾ, ਕੀ ਮੁੜ-ਨਿਰਮਾਣ ਪੈਦਾ ਕਰਦਾ ਹੈ , ਅਤੇ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਦੌਰਾਨ ਕਲਾਇੰਟ ਕੀ ਕਰਦਾ ਹੈ। ਉਸ ਵਾਕ ਤੋਂ ਬਿਨਾਂ, ਹਰ ਭਵਿੱਖੀ ਘਟਨਾ ਇਹੀ ਬਹਿਸ ਦੁਬਾਰਾ ਖੋਲ੍ਹਦੀ ਹੈ ਕਿ keepalive ਬਹੁਤ ਛੋਟਾ ਹੈ ਜਾਂ ਮੁੜ ਕਨੈਕਟ ਬਹੁਤ ਹੌਲੀ।
ਸੀਮਾਵਾਂ ਬਾਰੇ WireGuard ਦੇ ਨੋਟ ਇੱਕ ਲਾਹੇਵੰਦ ਯਾਦ ਦਿਵਾਉਂਦੇ ਹਨ ਕਿ keepalive ਵਿਚਕਾਰਲੇ ਡੱਬਿਆਂ ਲਈ ਇੱਕ ਬਦਲਵਾਂ ਰਾਹ ਹੈ, ਜੀਵਨ-ਸ਼ਕਤੀ ਦਾ ਆਮ ਡਿਜ਼ਾਈਨ ਨਹੀਂ। ਜਿਸ ਸਮੱਸਿਆ ਨੂੰ ਇਹ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦਾ ਉਸਦੇ ਜਵਾਬ ਵਿੱਚ ਬਾਰੰਬਾਰਤਾ ਵਧਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਸੀਮਾ ਪੜ੍ਹੋ।