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 فراخوانی‌های برگشتی را توصیف می‌کند که دسترس‌پذیری را از تغییر شبکه پیش‌فرض جدا می‌کنند و گزارش شما به همان تمایز نیاز دارد. هر چیز دیگری داستانی درباره رانندگی است.