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 ನ ಸಂಪರ್ಕ ದಾಖಲೆಗಳು ಲಭ್ಯತೆಯನ್ನು ಡೀಫಾಲ್ಟ್ ನೆಟ್‌ವರ್ಕ್ ಬದಲಾವಣೆಯಿಂದ ಪ್ರತ್ಯೇಕಿಸುವ ಕರೆಹಿಂತಿರುಗಿಸುವಿಕೆಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ, ಮತ್ತು ನಿಮ್ಮ ವರದಿಗೆ ಬೇಕಾಗಿರುವುದು ನಿಖರವಾಗಿ ಆ ವ್ಯತ್ಯಾಸ. ಉಳಿದದ್ದೆಲ್ಲ ಪ್ರಯಾಣದ ಕಥೆ.