اجارهٔ جایگزین پس از بازگشت تونل سایت: تمدید کنیم یا صبر کنیم؟

پیوند سایت برقرار است، تونل ساخته شده، و رایانه‌های شعبه هنوز به سرور فایل دسترسی ندارند. در طول قطعی دو ساعت در حال کار بود و تنها یکی از آن‌ها تمام شده است. تونل زمانی بازیابی شد که مسیر رمزگذاری‌شده بازگشت؛ نشانی هر کلاینت زمانی بازیابی می‌شود که اجارهٔ کنونی‌اش پایان یابد یا جایگزین شود. مقایسهٔ این دو خط زمانی شکاف را سریع‌تر از خواندن گزارش‌های دیوار آتش توضیح می‌دهد.

دو ساعت، و یکی از آن‌ها تونل نیست

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

پیاده‌سازی و نسخهٔ نرم‌افزار را به این گزاره پیوست نگه دارید. نام تایمرها و مقادیر پیش‌فرض میان نسخه‌های SonicOS فرق می‌کند، و یک رابط قدیمی ثابت نمی‌کند که رابط جدیدتر چه می‌کند.

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

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

ipconfig /all
ipconfig /release
ipconfig /renew

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

پیشنهاد را بخوانید، نه فقط نشانی را

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

tcpdump -ni any 'port 67 or port 68'

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

جایی که مقایسه وارونه می‌شود

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

اگر تنها یک کلاینت آسیب دیده باشد در حالی که همسایه‌هایش خوب‌اند، عکس آن درست است: اجارهٔ آن کلاینت، رزرو آن یا رفتار کلاینت DHCP خودش متغیر است، و تغییری در مقیاس کل سایت ابزار نادرستی است.

نشانی‌های ایستا و رزروها پاسخ سوم را می‌خواهند. کلاینتی که به یک نشانی سنجاق شده با تمدید نجات نمی‌یابد، و رزروی که با محدودهٔ جایگزین برخورد می‌کند نسخهٔ تکراری می‌سازد که تا وقتی دو طرح نشانی را مقایسه نکنید شبیه خرابی مسیریابی به نظر می‌رسد.

رویهٔ خروج را بنویسید

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

با تأیید منبع تمام کنید، نه نشانی. رسیدن به سرور فایل، تحلیل نام آن و رسیدن به اینترنت سه بررسی جداست، و تنها مورد آخر هرگز مورد تردید نبود.