IKEv2 ਮਰੇ ਸਾਥੀ ਦੀ ਖੋਜ ਤੁਹਾਡੀ ਐਪ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕਰਦੀ

IKEv2 ਜੀਵੰਤਤਾ ਜਾਂਚ ਇੱਕ ਸਵਾਲ ਪੁੱਛਦੀ ਹੈ: ਕੀ ਦੂਜਾ ਸਾਥੀ ਸੁਰੱਖਿਅਤ ਨਿਯੰਤਰਣ ਸੰਬੰਧ ਉੱਤੇ ਅਜੇ ਵੀ ਜਵਾਬ ਦੇ ਰਿਹਾ ਹੈ। ਇਹ ਨਹੀਂ ਮਾਪਦੀ ਕਿ ਅੰਦਰੂਨੀ ਐਪਲੀਕੇਸ਼ਨ ਸਿਹਤਮੰਦ ਹੈ, ਗੇਟਵੇ ਪਿੱਛੇ ਮਾਰਗ ਮੌਜੂਦ ਹੈ, ਜਾਂ ਬ੍ਰਾਊਜ਼ਿੰਗ ਤੇਜ਼ ਲੱਗਦੀ ਹੈ। ਸੁਰੰਗ ਪਿੱਛੇ ਦੀ ਹਰ ਲਾਭਦਾਇਕ ਚੀਜ਼ ਫੇਲ੍ਹ ਹੋਣ 'ਤੇ ਵੀ ਜਾਂਚ ਪਾਸ ਹੋ ਸਕਦੀ ਹੈ।

ਟਾਈਮਰ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਕਿਸਮਾਂ ਦੇ ਸਬੂਤ ਵੱਖਰੇ ਪੜ੍ਹੋ।

ਜੀਵੰਤਤਾ ਜਾਂਚ ਅਸਲ ਵਿੱਚ ਕੀ ਪੁੱਛਦੀ ਹੈ

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

ਇਹੀ ਫ਼ਰਕ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਸੈਸ਼ਨ ਚੁੱਪ ਹੋਣ 'ਤੇ ਕਿੱਥੇ ਵੇਖਣਾ ਹੈ। ਡੇਟਾ ਮਾਰਗ ਟੁੱਟਿਆ ਹੋਣ 'ਤੇ ਵੀ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਸਾਥੀ ਨੀਤੀ, ਰਾਊਟਿੰਗ ਜਾਂ ਹੇਠਲੀ ਸੇਵਾ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰਨ ਵਾਲਾ ਸਾਥੀ ਪਹੁੰਚ ਜਾਂ ਦੂਰਲੇ ਸਿਰੇ ਦੀ ਆਪਣੀ ਹਾਲਤ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।

ਬ੍ਰਾਊਜ਼ਰ ਤੋਂ ਪਹਿਲਾਂ ਸੁਰੱਖਿਆ ਸੰਘ ਪੜ੍ਹੋ

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

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

ਸ਼ਿਕਾਇਤ ਵੇਲੇ ਦੇ ਕਾਊਂਟਰਾਂ ਸਮੇਤ ਹਾਲਤਾਂ ਦੇ ਨਾਮ ਟਿਕਟ ਵਿੱਚ ਜਿਵੇਂ ਹਨ ਤਿਵੇਂ ਲਿਖੋ। ਸੁਰੰਗ ਹੇਠਾਂ ਵਰਗਾ ਵੇਰਵਾ ਲੁਕਾਉਂਦਾ ਹੈ ਕਿ ਦੋਵਾਂ ਸੰਘਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਖਤਮ ਹੋਇਆ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਇਹੀ ਇੱਕੋ-ਇੱਕ ਤੱਥ ਹੁੰਦਾ ਹੈ ਜੋ ਰੱਖਣ ਯੋਗ ਹੈ।

ਮਾਰਗ ਫੇਲ੍ਹ ਹੋਣਾ ਮਰੇ ਸਾਥੀ ਵਰਗਾ ਹੀ ਦਿਸਦਾ ਹੈ

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

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

ਟਾਈਮਰ ਨਿਦਾਨ ਤੋਂ ਦੂਰ ਰੱਖੋ

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

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

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