VPN ਗੱਡੀ ਚਲਾਉਂਦਿਆਂ ਦੁਬਾਰਾ ਜੁੜਦਾ ਹੈ: ਰੇਡੀਓ ਬਦਲਾਅ ਜਾਂ IP ਬਦਲਾਅ?
ਟਾਵਰਾਂ ਵਿਚਕਾਰ ਹੈਂਡਓਵਰ IP ਰਾਹ ਨੂੰ ਅਛੂਤ ਛੱਡ ਸਕਦਾ ਹੈ। ਜੋ ਕਲਾਇੰਟ ਟਨਲ ਨੂੰ ਖਿਸਕਾਉਂਦੇ ਹਨ ਉਨ੍ਹਾਂ ਦੀ ਤੁਲਨਾ ਉਨ੍ਹਾਂ ਨਾਲ ਕਰੋ ਜੋ ਇਸਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ ਨੈੱਟਵਰਕ ਦੀ ਘਟਨਾ ਪੜ੍ਹੋ, ਸਫ਼ਰ ਨਹੀਂ।
ਜਦੋਂ ਤੁਸੀਂ ਕਸਬੇ ਦੇ ਕਿਨਾਰੇ ਤੋਂ ਲੰਘਦੇ ਹੋ ਤਾਂ ਕਾਲ ਕੱਟ ਜਾਂਦੀ ਹੈ, ਅਤੇ VPN ਦਾ ਆਈਕਨ ਉਸੇ ਪਲ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਸਨੂੰ “ਟਾਵਰ ਬਦਲਣ ਨੇ ਟਨਲ ਮਾਰ ਦਿੱਤੀ” ਵਜੋਂ ਦਰਜ ਕਰਨਾ ਲੋਭਵਾਨ ਹੈ। ਦੋ ਵੱਖਰੀਆਂ ਗੱਲਾਂ ਹੋਈਆਂ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਟਾਵਰਾਂ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ। ਇੱਕ ਰੇਡੀਓ ਹੈਂਡਓਵਰ ਤੁਹਾਡਾ IP ਪਤਾ, ਡਿਫ਼ਾਲਟ ਰਾਹ ਅਤੇ ਸ਼ੈਸ਼ਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਛੂਤ ਛੱਡ ਸਕਦਾ ਹੈ, ਜਦਕਿ ਸੱਚਾ ਪਤਾ ਬਦਲਾਅ ਹਰ ਉਸ ਟਨਲ ਨੂੰ ਤੋੜ ਦੇਵੇਗਾ ਜੋ ਇਸ ਦੇ ਨਾਲ ਨਹੀਂ ਖਿਸਕ ਸਕਦੀ। ਕਲਾਇੰਟ ਉਸ ਦੂਜੀ ਸਥਿਤੀ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦੇ ਹਨ ਇਸ ਦੀ ਤੁਲਨਾ ਕਰਨਾ ਹੀ ਲਾਹੇਵੰਦ ਅਭਿਆਸ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਰਚਿਆ ਹੋਇਆ ਵਿਵਹਾਰ ਦੇਖ ਰਹੇ ਹੋ ਜਾਂ ਖਰਾਬੀ।
ਟਾਵਰ ਬਦਲਣਾ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਪਤਾ ਬਦਲਣਾ ਹੋਵੇ
ਮੋਬਾਇਲ ਨੈੱਟਵਰਕ ਹੈਂਡਓਵਰ ਦੌਰਾਨ ਪੈਕਟ ਸ਼ੈਸ਼ਨ ਨੂੰ ਜੀਵਿਤ ਰੱਖਦੇ ਹਨ, ਜਿੰਨਾ ਚਿਰ ਆਪਰੇਟਰ ਦਾ ਮੋਬਿਲਿਟੀ ਐਂਕਰ ਇੱਕੋ ਰਹੇ। ਰੇਡੀਓ ਲਿੰਕ ਬਦਲਦਾ ਹੈ, ਟਨਲ ਇਸਨੂੰ ਨੋਟਿਸ ਨਹੀਂ ਕਰਦੀ, ਅਤੇ ਕਿਸੇ ਵੀ ਲੌਗ ਵਿੱਚ ਦੁਬਾਰਾ ਜੁੜਨਾ ਨਹੀਂ ਦਿਸਣਾ ਚਾਹੀਦਾ। ਸ਼ਹਿਰ ਦੇ ਅੰਦਰ ਆਵਾਜਾਈ ਲਈ ਇਹੀ ਆਮ ਸਥਿਤੀ ਹੈ।
ਪਤਾ ਉਹ ਬਦਲਦਾ ਹੈ ਜੋ ਐਂਕਰਾਂ ਵਿਚਕਾਰ ਤਬਦੀਲੀ, Wi-Fi ਤੋਂ ਸੈਲੂਲਰ ਤੇ ਜਾਣਾ, ਜਾਂ ਲੰਮੇ ਅੰਤਰਾਲ ਤੋਂ ਬਾਅਦ ਆਪਰੇਟਰ ਵੱਲ ਟਨਲ ਦੀ ਮੁੜ ਸਥਾਪਨਾ ਹੈ। ਉਹ ਘਟਨਾਵਾਂ ਤੁਹਾਡੇ ਪੈਕਟਾਂ ਵੱਲੋਂ ਲਿਜਾਏ ਸਰੋਤ ਪਤੇ ਦੀ ਥਾਂ ਲੈਂਦੀਆਂ ਹਨ, ਅਤੇ VPN ਸਾਥੀ ਇੱਕ ਖਿਸਕੇ ਹੋਏ ਸਾਥੀ ਨੂੰ ਵੇਖਦਾ ਹੈ।
ਵਿਹਾਰਕ ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਆਵਾਜਾਈ ਸਬੂਤ ਨਹੀਂ ਹੈ। ਚਾਲੀ ਕਿਲੋਮੀਟਰ ਗਿਆ ਉਪਕਰਣ ਪੂਰੇ ਰਾਹ ਇੱਕ ਹੀ ਪਤਾ ਰੱਖ ਸਕਦਾ ਹੈ, ਅਤੇ ਸਥਿਰ ਖੜ੍ਹਾ ਉਪਕਰਣ ਦੋ ਵਾਰ ਪਤਾ ਬਦਲ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਨੈੱਟਵਰਕ ਨੇ ਇਸ ਤਰ੍ਹਾਂ ਫੈਸਲਾ ਕੀਤਾ। ਘਟਨਾ ਦਰਜ ਕਰਨਾ ਹੀ ਉਨ੍ਹਾਂ ਦੋਹਾਂ ਵਿੱਚ ਫ਼ਰਕ ਕਰਨ ਦਾ ਇੱਕੋ-ਇੱਕ ਤਰੀਕਾ ਹੈ।
ਦੋ ਰਚਨਾਵਾਂ: ਟਨਲ ਖਿਸਕਾਓ ਜਾਂ ਦੁਬਾਰਾ ਬਣਾਓ
ਕਲਾਇੰਟ ਇਸ ਗੱਲ ਵਿੱਚ ਵੱਖਰੇ ਹਨ ਕਿ ਬਾਹਰੀ ਸਰੋਤ ਬਦਲਣ ਦੀ ਉਨ੍ਹਾਂ ਨੂੰ ਕਿੰਨੀ ਪਰਵਾਹ ਹੈ। ਕੁਝ ਟਨਲ ਨੂੰ ਉਸ ਪਤੇ ਨਾਲ ਬੰਨ੍ਹਦੇ ਹਨ ਜਿਸ ਤੇ ਇਹ ਬਣੀ ਸੀ ਅਤੇ ਪੂਰੀ ਮੁੜ ਸਥਾਪਨਾ ਮੰਗਦੇ ਹਨ। ਹੋਰ ਹਰ ਪੈਕਟ ਨੂੰ ਸੁਤੰਤਰ ਤੌਰ ਤੇ ਤਸਦੀਕ ਕਰਦੇ ਹਨ ਅਤੇ ਸਿਰਫ਼ ਇਹ ਅਪਡੇਟ ਕਰਦੇ ਹਨ ਕਿ ਜਵਾਬ ਕਿੱਥੇ ਭੇਜਣੇ ਹਨ।
| Mechanism | Behaviour after the source changes | What the user notices |
|---|---|---|
| WireGuard | Endpoint updated on the next authenticated packet | Usually nothing; the tunnel continues |
| IKEv2 with MOBIKE | Security association moves to the new address | Short pause, no re-authentication |
| OpenVPN over UDP with float | Peer address may change without a restart | Might survive, depending on timing |
| Client bound to one address | Session dies and is rebuilt | A visible reconnect and a new authentication |
ਉੱਪਰਲੀ ਕਤਾਰ ਬਹੁਤ ਸਾਰੀਆਂ ਉਲਝੀਆਂ ਰਿਪੋਰਟਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ। WireGuard ਕੋਲ ਤੋੜਨ ਵਾਲਾ ਕੋਈ ਸ਼ੈਸ਼ਨ ਨਹੀਂ: ਹਰ ਪੈਕਟ ਸਾਥੀ ਦਾ ਸੂਚਕ ਲੈ ਕੇ ਚੱਲਦਾ ਹੈ ਅਤੇ ਤਸਦੀਕ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਨਵੇਂ ਪਤੇ ਤੋਂ ਆਉਣ ਵਾਲਾ ਵੈਧ ਪੈਕਟ ਪਰਿਭਾਸ਼ਾ ਅਨੁਸਾਰ ਉਸੇ ਸਾਥੀ ਦਾ ਹੈ, ਅਤੇ ਦਰਜ ਕੀਤਾ ਅੰਤ ਬਿੰਦੂ ਉਸ ਦਾ ਪਿੱਛਾ ਕਰਦਾ ਹੈ। ਸਫ਼ਰ ਭਰ ਲਗਾਤਾਰ “ਜੁੜਿਆ” ਦਿਖਾਉਣ ਵਾਲਾ ਕਲਾਇੰਟ ਸੱਚ ਬੋਲ ਰਿਹਾ ਹੈ।
ਹੇਠਲੀ ਕਤਾਰ ਵੀ ਖਰਾਬੀ ਨਹੀਂ। ਸ਼ੈਸ਼ਨ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਮੌਜੂਦਾ ਪਤੇ ਵਿਰੁੱਧ ਤਸਦੀਕ ਦੁਬਾਰਾ ਚਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਪੁਰਾਣਾ ਪਤਾ ਹੁਣ ਕਿਸੇ ਹੋਰ ਦਾ ਹੋ ਸਕਦਾ ਹੈ—ਤਦ ਤੁਸੀਂ ਠੀਕ ਇਹੀ ਚਾਹੁੰਦੇ ਹੋ।
ਆਵਾਜਾਈ ਨਹੀਂ, ਘਟਨਾ ਵੇਖੋ
Android ਵਿੱਚ ਕਨੈਕਟੀਵਿਟੀ ਉਪਪ੍ਰਣਾਲੀ ਨੈੱਟਵਰਕ ਬਦਲਾਅ ਘਟਨਾਵਾਂ ਵਜੋਂ ਰਿਪੋਰਟ ਕਰਦੀ ਹੈ, ਅਤੇ ਉਹੀ ਤੁਹਾਨੂੰ ਕਲਾਇੰਟ ਦੇ ਵਿਵਹਾਰ ਨਾਲ ਜੋੜਨੇ ਚਾਹੀਦੇ ਹਨ। ਡੰਪ ਲੰਮਾ ਹੈ, ਪਰ ਸੰਬੰਧਿਤ ਹਿੱਸੇ ਡਿਫ਼ਾਲਟ ਨੈੱਟਵਰਕ ਅਤੇ ਉਸ ਦਾ ਪਤਾ ਹਨ:
adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40ਸਰਵਰ ਵੱਲ ਰੋਮਿੰਗ ਸਥਿਤੀ ਲਈ ਸਿੱਧਾ ਮਾਪ ਹੈ। WireGuard ਹਰ ਸਾਥੀ ਲਈ ਆਖ਼ਰੀ ਤਸਦੀਕ ਕੀਤਾ ਅੰਤ ਬਿੰਦੂ ਸੰਗ੍ਰਹਿ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਪਤਾ ਬਦਲਾਅ ਦੁਬਾਰਾ ਜੁੜਨ ਵਜੋਂ ਨਹੀਂ ਬਲਕਿ ਬਦਲੇ ਮੁੱਲ ਵਜੋਂ ਦਿਸਦਾ ਹੈ:
sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakesਸਫ਼ਰ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਅੰਤ ਬਿੰਦੂ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਜੇ ਪਤਾ ਅਤੇ ਪੋਰਟ ਬਦਲੇ ਨਹੀਂ, ਤਾਂ ਟਨਲ ਨੂੰ ਕੁਝ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ ਅਤੇ ਦੁਬਾਰਾ ਜੁੜਨਾ ਕਿਤੇ ਹੋਰੋਂ, ਆਮ ਤੌਰ ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਆਇਆ। ਜੇ ਅੰਤ ਬਿੰਦੂ ਬਦਲਿਆ ਪਰ ਹੈਂਡਸ਼ੇਕ ਦੀ ਸਮਾਂ-ਮੋਹਰ ਆਮ ਕੁੰਜੀ ਨਵੀਨੀਕਰਨ ਅੰਤਰਾਲ ਦੇ ਨੇੜੇ ਰਹੀ, ਤਾਂ ਟਨਲ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਹੋਣ ਦੀ ਬਜਾਏ ਖਿਸਕ ਗਈ।
ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਹੋਣਾ ਵੱਖਰਾ ਦਿਸਦਾ ਹੈ: ਹੈਂਡਸ਼ੇਕ ਦੀ ਸਮਾਂ-ਮੋਹਰ ਦੁਬਾਰਾ ਜੁੜਨ ਦੇ ਪਲ ਤੇ ਰੀਸੈੱਟ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਸ਼ਾਂਤ ਨਿਰੰਤਰਤਾ ਦੀ ਬਜਾਏ ਸ਼ੁਰੂਆਤੀ ਕ੍ਰਮ ਲੌਗ ਕਰਦਾ ਹੈ।
ਦੁਬਾਰਾ ਜੁੜਨਾ ਕਦੋਂ ਸਹੀ ਵਿਵਹਾਰ ਹੈ
ਹਰ ਦੁਬਾਰਾ ਜੁੜਨ ਨੂੰ ਖਰਾਬੀ ਮੰਨਣ ਨਾਲ ਅਜਿਹੀਆਂ ਸੰਰਚਨਾਵਾਂ ਬਣਦੀਆਂ ਹਨ ਜੋ ਮਰੀਆਂ ਸ਼ੈਸ਼ਨਾਂ ਨੂੰ ਜੀਵਿਤ ਰੱਖਦੀਆਂ ਹਨ। ਜਿਸ ਸਾਥੀ ਦਾ ਪਤਾ ਬਦਲਿਆ ਕਿਉਂਕਿ ਨੈੱਟਵਰਕ ਨੇ ਇਸਨੂੰ ਮੁੜ ਵੰਡਿਆ, ਉਸਨੂੰ ਪੁਰਾਣੀ ਮੈਪਿੰਗ ਲਈ ਟ੍ਰੈਫਿਕ ਲੈਣਾ ਜਾਰੀ ਨਹੀਂ ਰੱਖਣਾ ਚਾਹੀਦਾ, ਅਤੇ ਚੁੱਪਚਾਪ ਜਾਰੀ ਰਹਿਣ ਵਾਲਾ ਕਲਾਇੰਟ ਆਈਕਨ ਹਰਾ ਰਹਿੰਦਿਆਂ ਕਾਲੇ ਟੋਏ ਵਿੱਚ ਭੇਜ ਸਕਦਾ ਹੈ।
ਵਰਤੋਂਕਾਰ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਦੋਵੇਂ ਅਸਫਲਤਾਵਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਦੁਬਾਰਾ ਜੁੜਨ ਵਿੱਚ ਕੁਝ ਸਕਿੰਟ ਅਤੇ ਨਵੀਂ ਤਸਦੀਕ ਲੱਗਦੀ ਹੈ। ਪੁਰਾਣੀ ਟਨਲ ਵਿੱਚ ਅਜਿਹੀ ਐਪਲੀਕੇਸ਼ਨ ਲੱਗਦੀ ਹੈ ਜੋ ਬਿਨਾਂ ਗਲਤੀ ਦੇ ਅਟਕ ਜਾਂਦੀ ਹੈ, ਜਿਸਨੂੰ ਸਮਝਾਉਣਾ ਕਿਤੇ ਵੱਧ ਔਖਾ ਹੈ ਅਤੇ “ਇੰਟਰਨੈੱਟ ਖਰਾਬ ਹੋ ਗਿਆ” ਵਜੋਂ ਰਿਪੋਰਟ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਕਿਤੇ ਵੱਧ ਹੈ।
ਇਸ ਦੇ ਹੇਠ ਨੀਤੀ ਦਾ ਸਵਾਲ ਵੀ ਲੁਕਿਆ ਹੈ। ਇੱਕ ਰਾਹ ਗੁਆਉਣ ਅਤੇ ਦੂਜਾ ਸਥਾਪਿਤ ਕਰਨ ਵਿਚਕਾਰਲੇ ਅੰਤਰਾਲ ਵਿੱਚ ਕੁਝ ਕਲਾਇੰਟ ਸਿੱਧਾ ਟ੍ਰੈਫਿਕ ਭੇਜਣ ਵੱਲ ਮੁੜ ਜਾਂਦੇ ਹਨ। ਇਸਨੂੰ ਰੋਕਣਾ ਸਵੈਚਾਲਿਤ ਬਹਾਲੀ ਤੋਂ ਵੱਖਰਾ ਨਿਯੰਤਰਣ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਇੱਕ ਵਿੱਚ ਚੰਗਾ ਅਤੇ ਦੂਜੇ ਵਿੱਚ ਮਾੜਾ ਹੋ ਸਕਦਾ ਹੈ। ਕੋਈ ਵੀ ਟਿਊਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਤੁਹਾਨੂੰ ਕਿਹੜਾ ਚਾਹੀਦਾ ਹੈ।
ਦੇਖਿਆ ਗਿਆ ਕ੍ਰਮ ਲਿਖੋ
ਲਾਹੇਵੰਦ ਰਿਪੋਰਟ ਘਟਨਾ ਦੇ ਸਰੋਤ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ: ਨਵੇਂ ਪਤੇ ਨਾਲ ਡਿਫ਼ਾਲਟ ਨੈੱਟਵਰਕ ਬਦਲਾਅ, Wi-Fi ਤੋਂ ਸੈਲੂਲਰ ਤੇ ਜਾਣਾ, ਜਾਂ ਬਿਨਾਂ ਕਿਸੇ ਪਤਾ ਬਦਲਾਅ ਦੇ ਹੈਂਡਓਵਰ। ਫਿਰ ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਕਲਾਇੰਟ ਨੇ ਕੀ ਕੀਤਾ, ਯਾਦ ਤੋਂ ਨਹੀਂ ਬਲਕਿ ਸਰਵਰ ਵੱਲ ਦੀ ਸਮਾਂ-ਮੋਹਰ ਨਾਲ।
ਜੇ ਟਨਲ ਖਿਸਕੀ ਹੈ ਤਾਂ ਇਹ ਕਹੋ ਅਤੇ ਨਵਾਂ ਅੰਤ ਬਿੰਦੂ ਪਰਿਵਾਰ ਨੋਟ ਕਰੋ। ਜੇ ਦੁਬਾਰਾ ਸਥਾਪਿਤ ਹੋਈ ਹੈ ਤਾਂ ਨੋਟ ਕਰੋ ਕਿ ਤਸਦੀਕ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਸਫਲ ਹੋਈ ਅਤੇ ਅੰਤਰਾਲ ਕਿੰਨਾ ਰਿਹਾ। ਇਹ ਤਿੰਨ ਤੱਥ ਸਿਹਤਮੰਦ ਮੋਬਾਇਲ ਰਚਨਾ ਨੂੰ ਨੈੱਟਵਰਕਾਂ ਵਿਚਕਾਰ ਭਟਕਦੇ ਕਲਾਇੰਟ ਤੋਂ ਵੱਖਰਾ ਕਰਦੇ ਹਨ।
ਅਤੇ “ਟਾਵਰ ਬਦਲਾਅ” ਵਾਕਾਂਸ਼ ਤੋਂ ਬਚੋ, ਜਿੰਨਾ ਚਿਰ ਉਪਕਰਣ ਦਾ ਲੌਗ ਸੱਚਮੁੱਚ ਇਸਨੂੰ ਸਥਾਪਿਤ ਨਾ ਕਰੇ। Android ਦੇ ਕਨੈਕਟੀਵਿਟੀ ਦਸਤਾਵੇਜ਼ ਉਹ ਕਾਲਬੈਕ ਦੱਸਦੇ ਹਨ ਜੋ ਉਪਲਬਧਤਾ ਨੂੰ ਡਿਫ਼ਾਲਟ ਨੈੱਟਵਰਕ ਬਦਲਾਅ ਤੋਂ ਵੱਖ ਕਰਦੇ ਹਨ, ਅਤੇ ਤੁਹਾਡੀ ਰਿਪੋਰਟ ਨੂੰ ਠੀਕ ਉਹੀ ਫ਼ਰਕ ਚਾਹੀਦਾ ਹੈ। ਬਾਕੀ ਸਭ ਗੱਡੀ ਚਲਾਉਣ ਦੀ ਕਹਾਣੀ ਹੈ।