نشانی IP در WAN تغییر کرد و تونل قطع شد: بررسی‌ها به ترتیب

تونل قطع می‌شود، روتر یک اتصال دوباره را ثبت می‌کند و هیچ چیز در شبکه محلی جابه‌جا نشده است. نشانی WAN جدید اتصال بیرونی را باطل می‌کند بدون اینکه چیزی در داخل تغییر کند: نشانی مبدأ کلاینت تغییر کرده، وضعیت NAT قدیمی به مبدأیی اشاره می‌کند که دیگر وجود ندارد و همتای دور ممکن است هنوز به نشانی قبلی بفرستد. بازیابی رفتار عادی است و پرسش مفید این است که کدام وضعیت به‌روزرسانی نشد.

پیش از خواندن گزارش، رویداد را نام‌گذاری کنید

بررسی کنید که واقعاً در لایه دسترسی چه رخ داده است. تمدید اجاره ارائه‌دهنده یک رویداد است. جلسه PPPoE که دوباره متصل شده رویدادی دیگر است. مودم فیبری که راه‌اندازی مجدد شده، یا تغییر مسیر WAN از یک اتصال بالادست به دیگری، نشانی بیرونی یا مسیر آن را به روش سومی تغییر می‌دهد. این‌ها یک رویداد نیستند و باقی‌مانده یکسانی بر جا نمی‌گذارند.

خط اتصال دوباره در گزارش VPN نیز اثبات تغییر WAN نیست. مهلت بی‌کاری، فاصله احراز هویت دوباره و تشخیص همتای مرده همگی اتصال دوباره بدون هیچ تغییر نشانی تولید می‌کنند. پیش از هر نتیجه‌گیری، مُهرهای زمانی گزارش دسترسی را با گزارش VPN مقایسه کنید و پنجره مقایسه را به‌قدر کافی گسترده نگه دارید تا تغییری را که در شب رخ داده است بگیرد.

رومینگ و اتصال دوباره پروتکل‌های متفاوتی هستند

WireGuard رومینگ احرازشده را درون پروتکل دارد: وقتی همتایی بسته‌ای درست احرازشده از نشانی مبدأ جدید دریافت می‌کند، نقطه پایانی آن همتا را به‌روز می‌کند. آغاز سریع WireGuard پیکربندی همتایی را توصیف می‌کند که این را ممکن می‌سازد، و به همین دلیل کلاینتی که نشانی‌اش تغییر می‌کند اغلب بدون راه‌اندازی مجدد قابل مشاهده بازیابی می‌شود.

OpenVPN به‌طور پیش‌فرض متفاوت رفتار می‌کند. یک جلسه UDP می‌تواند پایان یابد و دوباره متصل شود، و رفتار اختیاری float به همتای احرازشده اجازه می‌دهد در جایی که پیکربندی اجازه می‌دهد از نشانی جدید ادامه دهد. تونل‌های مبتنی بر TCP سخت‌گیرترند، زیرا خود اتصال به جفت نشانی گره خورده است. همان تفاوت تعیین می‌کند که بازیابی نامرئی به نظر برسد یا هر بار در گزارش خود را اعلام کند.

هیچ‌یک از این دو رفتار درباره برنامه‌های درون چیزی نمی‌گوید. تونل بازیابی‌شده جلسه TCP را که همتا از قبل مرده می‌دانست بازنمی‌گرداند.

وضعیتی که تونل مالک آن نیست

وضعیت ترجمه و مسیریابی به روش‌هایی از اتصال دوباره جان سالم به در می‌برد که مردم را شگفت‌زده می‌کند. ورودی conntrack که برای مبدأ قدیمی ساخته شده، مسیر پاسخ را به نشانی‌ای که دیگر وجود ندارد میخکوب نگه می‌دارد، و بر اساس برنامه خودش منقضی می‌شود، نه وقتی تونل برگشت. راه‌اندازی مجدد سرویس تونل آن انتظار را کوتاه نمی‌کند، پس پیوند تعمیرشده ممکن است مدتی هنوز خراب به نظر برسد.

مسیرها و قواعد سیاست می‌توانند به دروازه یا رابط قدیمی ارجاع دهند. مجموعه قواعدی که پیش از تغییر WAN درست بود ممکن است به دستگاهی اشاره کند که اکنون از کار افتاده است، که تونلی تولید می‌کند که اتصال را گزارش می‌دهد و ترافیکی که به جایی نمی‌رود. DNS پویا برای سروری که میزبانی می‌کنید مسئله‌ای جدا از کلاینتی است که مبدأ جدیدی می‌گیرد. رکورد باید به‌روزرسانی شود تا کلاینت‌های دور شما را پیدا کنند، و هیچ پیکربندی سمت کلاینت نشانی‌ای را جبران نمی‌کند که ترجمه در بالادست آن را ارسال نخواهد کرد.

بررسی‌ها را از بیرون به درون مرتب کنید

ترتیب زیر از اتصال بیرونی به درون می‌رود، و توقف در نخستین گام شکست‌خورده همان چیزی است که آن را مفید می‌کند: هر گذر لایه بالای خود را کنار می‌گذارد. این ترتیب را حتی وقتی عیب آشکار به نظر می‌رسد نگه دارید.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

فرمان اول نقطه پایانی کنونی و سن دست‌دادن را برای هر همتا نشان می‌دهد. دومی و سومی نشان می‌دهند که آیا رابط بیرونی و مسیر به نقطه پایانی هنوز معنا دارند. شمار conntrack یک بررسی درشت برای وضعیت باقی‌مانده از نشانی قبلی است و گزارش جایی است که دلیل اتصال دوباره ثبت می‌شود.

سپس از کلاینت شبکه محلی آزمایش کنید، نه از روتر. پینگ که خود روتر فرستاده است مسیری متفاوت از ترافیک ارسال‌شده دارد، بنابراین پینگ موفق از روتر ثابت می‌کند که تونل وجود دارد و هیچ چیز درباره دسترسی کلاینت نمی‌گوید.

رفتار مورد انتظار را تعیین و آن را بنویسید

اتصال دوباره رفتار درستی برای بیشتر استقرارهاست، پس هدف جلوگیری از آن نیست. در عوض تعیین کنید که در فاصله زمانی با ترافیک چه باید بشود: متوقف شود، نگه داشته شود، یا به مسیر دیگری منتقل شود. آن تصمیم به دیوار آتش و سیاست مسیریابی تعلق دارد، نه به مشخصات VPN.

رویدادهای دسترسی و زمان‌های اتصال دوباره را یک هفته با هم ثبت کنید. تغییرهای تکرارشده بدون رویداد دسترسی متناظر به سرویس دسترسی اشاره می‌کنند، و جایگزینی مشخصات VPN اتصال بالادستی را که مدام دوباره مذاکره می‌کند درست نمی‌کند. یک جفت ورودی در همان دقیقه پرسش را برای آن حادثه حل می‌کند و به حادثه بعدی خط پایه می‌دهد.