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

ਪਛਾਣ ਉਹ ਚਾਬੀ ਹੈ ਜਿਸ ਹੇਠ ਸਰਵਰ ਤੁਹਾਨੂੰ ਰੱਖਦਾ ਹੈ

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

ਇਸ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਕਲਾਇੰਟ ਵਿੱਚ ਬੱਗ ਨਹੀਂ ਹੈ। ਕਲਾਇੰਟ ਨੇ ਉਹੀ ਭੇਜਿਆ ਜੋ ਪ੍ਰੋਫਾਈਲ ਨੇ ਕਿਹਾ ਸੀ।

ਗੇਟਵੇ ਤੋਂ ਟਕਰਾਅ ਕਿਵੇਂ ਦਿਸਦਾ ਹੈ

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

ObservationShared identityIdle teardown
Peer entries while both are awakeOne, with a changing addressOne per phone, or none
What triggers the dropThe other device connectingTime without traffic
What restores itThe other device disconnectingAny app needing the tunnel

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

ਨਕਲਾਂ ਕਿੱਥੋਂ ਆਉਂਦੀਆਂ ਹਨ

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

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

ਹਰ ਡਿਵਾਈਸ ਲਈ ਇੱਕ ਮੁੱਲ ਜਾਰੀ ਕਰੋ

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

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

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

ਦੋਵੇਂ ਫ਼ੋਨ ਜਾਗਦੇ ਰੱਖ ਕੇ ਪੁਸ਼ਟੀ ਕਰੋ

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

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

ਸੰਬੰਧਿਤ ਲੇਖ