ਜਦੋਂ ਨੈੱਟਵਰਕ ਬਦਲਦਾ ਹੈ ਤਾਂ MOBIKE IKEv2 VPN ਨੂੰ ਕਿਵੇਂ ਜੀਵਿਤ ਰੱਖਦਾ ਹੈ

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

ਬਦਲਾਅ ਨੂੰ ਪੜਾਵਾਂ ਵਿੱਚ ਦੇਖੋ, ਕਿਉਂਕਿ ਹਰ ਪੜਾਅ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ।

ਅੱਪਡੇਟ ਅਸਲ ਵਿੱਚ ਕੀ ਬਦਲਦਾ ਹੈ

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

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

ਕੀ ਤੁਹਾਡੀ ਪ੍ਰੋਫਾਈਲ ਸੱਚਮੁੱਚ ਇਸਨੂੰ ਸਮਰੱਥ ਕਰਦੀ ਹੈ

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

ਦੋਵੇਂ ਸਿਰਿਆਂ ਉੱਤੇ ਗੱਲਬਾਤ ਕੀਤੀ ਸਥਿਤੀ ਹੀ ਅਧਿਕਾਰ ਹੈ, ਉਤਪਾਦ ਪਰਿਵਾਰ ਦਾ ਦਸਤਾਵੇਜ਼ ਨਹੀਂ।

ਬਦਲਾਅ ਨੂੰ ਪੜਾਵਾਂ ਵਿੱਚ ਦੇਖੋ

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

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

ਫੇਲ੍ਹ ਦੀਆਂ ਪਰਤਾਂ ਵੱਖ ਕਰੋ

ਲੰਮੇ ਸਮੇਂ ਦਾ TCP ਸੈਸ਼ਨ IKEv2 ਅਦਲਾ-ਬਦਲੀ ਤੋਂ ਬਾਹਰਲੇ ਕਾਰਨਾਂ ਕਰਕੇ ਫੇਲ੍ਹ ਹੋ ਸਕਦਾ ਹੈ। ਨਵਾਂ ਨੈੱਟਵਰਕ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਫਿਲਟਰ, ਹੱਲ ਜਾਂ ਰੂਟ ਕਰ ਸਕਦਾ ਹੈ। ਹੇਠਲਾ ਰਾਹ ਬਦਲਦਿਆਂ ਟਨਲ ਦਾ ਪਤਾ ਬਿਲਕੁਲ ਨਾ ਬਦਲ ਸਕਦਾ ਹੈ। ਇਸੇ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਦੁਬਾਰਾ ਜੁੜਨਾ ਕੁਝ ਅਜਿਹਾ ਠੀਕ ਕਰ ਸਕਦਾ ਹੈ ਜੋ VPN ਨੇ ਕਦੇ ਨਹੀਂ ਤੋੜਿਆ।

ਰਿਕਵਰੀ ਦੌਰਾਨ ਵੀ ਰੋਕ ਨੀਤੀ ਨੂੰ ਥਾਂ ਉੱਤੇ ਰੱਖੋ।

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

ਜਦੋਂ ਇਹ ਦੁਹਰਾਇਆ ਜਾਵੇ ਤਾਂ ਕੀ ਦਰਜ ਕਰਨਾ ਹੈ

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

ਇਹ ਅਸਮਮਿਤੀ ਪਹਿਲੀ ਚੀਜ਼ ਪਰਖਣ ਯੋਗ ਹੋਣ ਜਿੰਨੀ ਆਮ ਹੈ।

ਰਿਕਾਰਡ ਹੱਥ ਵਿੱਚ ਹੋਣ ਨਾਲ, ਘਟਨਾ ਇੱਕ ਹੋਰ ਕੱਟਿਆ ਹੋਇਆ ਆਈਕਨ ਹੋਣਾ ਛੱਡ ਕੇ ਜਾਣੇ-ਪਛਾਣੇ ਮਾਲਕ ਵਾਲੇ ਕ੍ਰਮ ਦੀ ਇੱਕ ਘਟਨਾ ਬਣ ਜਾਂਦੀ ਹੈ। ਅਤੇ ਇਹੀ ਉਹ ਸਭ ਹੈ ਜੋ ਇੱਕ ਫੇਰੀ ਇਮਾਨਦਾਰੀ ਨਾਲ ਵਾਅਦਾ ਕਰ ਸਕਦੀ ਹੈ।