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

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

لایه اول: آیا WAN واقعاً برگشته است

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

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

لایه دوم: ساعت را پیش از گواهی بررسی کنید

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

date -u
chronyc tracking

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

لایه سوم: بخوانید تونل چه می‌گوید

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

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

لایه چهارم: از یک دستگاه پایین‌دستی آزمایش کنید

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

curl -s https://ifconfig.me
nslookup example.com

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

چه چیزی را اصلاح کنیم تا قطعی بعدی کوتاه‌تر باشد

اگر شکست تکرار شود، اصلاح ترتیب است نه پیکربندی: WAN را بالا بیاورید، سپس زمان، سپس تونل، سپس سیاست کلاینت. بیشتر روترها این را به‌صورت وابستگی یا تأخیر بیان می‌کنند و یک تأخیر کوتاه عمدی بهتر از بازنویسی پروفایل است.

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

مقالات مرتبط