تونل هنوز بالاست، مسیر رفته است: جدا کردن دو خرابی VPN
یک پیشوند می‌تواند در سه مرحله متفاوت دریافت، انتخاب و نصب شود. ابتدا جدول ارسال را بخوانید، سپس جدول پروتکل و سپس ساعت‌ها را.
یک میزبان غیرقابل‌دسترس می‌شود در حالی که رابط تونل هنوز خود را برقرار گزارش می‌کند، و این دو مشاهده با هم تناقض ندارند. چیزی مسیری را که ترافیک استفاده می‌کرد حذف کرده است: همسایه پیشوندش را پس گرفت، یک مسیر ایستای ردیابی‌شده برداشته شد، یا مسیر دیگری ترجیح داده شد. انجمن امنیتی می‌تواند در هر سه حالت کاملاً سالم بماند. جدا کردن رویدادها یعنی پرسیدن اینکه کدام لایه اول تغییر کرد، نه اینکه آیا VPN شکست خورد.
سه مرحله که شبیه یک رویداد به نظر می‌رسند
یک تصمیم مسیریابی سه مرحله دارد. پیشوند دریافت می‌شود، به‌عنوان بهترین انتخاب می‌شود و در جدول ارسال نصب می‌گردد. هر مرحله می‌تواند به‌تنهایی شکست بخورد، و خرابی از سمت برنامه یکسان به نظر می‌رسد. پیشوندی که آموخته شده اما انتخاب را باخته، از پیشوندی که هرگز نرسیده قابل تشخیص نیست وقتی تنها مدرکی که به آن نگاه می‌کنید جدول ارسال است.
به همین دلیل پرسش اول این است که کدام مرحله شکسته، نه اینکه کدام پروتکل مقصر است. پاسخ تعیین می‌کند که حادثه متعلق به کیست و بررسی بعدی از کدام ابزار استفاده می‌کند.
ابتدا مسیر نصب‌شده را بخوانید
از هسته بپرسید ترافیک مقصد معیوب واقعاً به کجا می‌رود. ip route get پرش بعدی، رابط و آدرس مبدأیی را که هسته استفاده می‌کرد چاپ می‌کند و برای یک مقصد پاسخ می‌دهد نه برای کل جدول. اگر پاسخ تونل را نام ببرد، جدول ارسال هنوز باور دارد که مسیر وجود دارد و مشکل بالاتر از آن است.
ip route get 10.20.5.10
ip route show 10.20.0.0/16پاسخ «unreachable» یعنی هیچ مسیر نصب‌شده‌ای وجود ندارد، که به یک پس‌گیری یا نصب ازقلم‌افتاده اشاره می‌کند. پاسخی که یک رابط فیزیکی را نام می‌برد یعنی ترافیک بدون اینکه کسی چنین تصمیمی بگیرد از تونل خارج شده، و بررسی بعدی همان ترجیحی است که برنده شد. اما پاسخی که تونل را نام می‌برد در حالی که بسته‌ها همچنان ناپدید می‌شوند، به پایین‌تر مسیر، به فیلترکردن یا به سمت دور اشاره دارد.
سپس به نمای خود پروتکل نگاه کنید
یک دیمن مسیریابی بیش از یک جدول نگه می‌دارد و مقایسه جالب بین آن‌هاست. در BGP، وضعیت نشست همسایه، اعلان دریافتی و مسیر نصب‌شده سه شاهد جداگانه‌اند. یک پیشوند می‌تواند در جدول دریافتی بماند و هرگز به هسته نرسد، چون مسیری با فاصله مدیریتی کوتاه‌تر برنده می‌شود. پیش از نتیجه‌گیری از اینکه طرف مقابل اعلان را متوقف کرده، هر سه را بررسی کنید.
vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"خلاصه به شما می‌گوید نشست برقرار است یا نه، نمای هر پیشوند می‌گوید پیشوند پذیرفته شده یا نه، و جست‌وجو در هسته می‌گوید نصب شده یا نه. خواندن آن‌ها به این ترتیب مانع می‌شود که لرزش نشست با پس‌گیری و پس‌گیری با رد سیاست اشتباه گرفته شود.
وقتی ساعت‌ها با هم نمی‌سازند
گزارش تونل، گزارش مسیریابی و اولین خرابی برنامه را با ساعت‌های واقعی‌شان روی یک خط زمانی بگذارید. اگر ازدست‌رفتن همسایه اول بیاید، تونل مسیر را با خودش پایین کشیده است. اگر پس‌گیری اول بیاید، مسیریابی تغییر کرده و تونل بعد از آن واکنش داده است. این‌ها حادثه‌های متفاوتی با صاحبان متفاوت‌اند و ترتیب تمام یافته است.
یک دقیقه اختلاف ساعت برای برگرداندن این نتیجه کافی است، پس پیش از اعتماد به ترتیب، منطقه زمانی و اختلاف را تأیید کنید. دستگاه‌هایی که بدون اختلاف در زمان محلی گزارش می‌دهند، منبع معمول یک خط زمانی مطمئن اما نادرست‌اند.
بازیابی بدون حلقه
پس از پس‌گیری دو مسیر می‌توانند واجد شرایط باشند: مسیری که پروتکل انتخاب می‌کند و مسیری که با دست سنجاق می‌کنید. تنها اولی تصمیمی است که شبکه همچنان برای شما می‌گیرد، به همین دلیل مسیر دستی یک راه‌حل موقت است نه برنامه بازیابی. اعلان جایگزین هم وضعیت فایروال یا NAT را برای نشستی که از قبل برقرار است حفظ نمی‌کند، بنابراین جریان‌های جدید ممکن است کار کنند در حالی که جریان اصلی خراب می‌ماند. تأیید کنید کدام پشتیبان باید فعال شود و آیا سایت دور از مسیر بازگشت را می‌پذیرد یا نه.
پیش از اینکه بفهمید چرا پس‌گیری رخ داده، یک بازنویسی ایستای دائمی نصب نکنید. این میان‌بر می‌تواند ترافیک را به مسیری شکست‌خورده سنجاق کند یا بی‌صدا از یک سیاست مسیریابی عامدانه عبور کند، و علت اصلی را زیر پیکربندی تازه دفن می‌کند. پس از بازگرداندن مسیر، برنامه را دوباره آزمایش کنید و تأیید کنید پیشوند انتخاب‌شده مسیر داده کاری دارد، نه فقط یک ورودی در جدول.