Ping اثبات نیست: مسیر میان دو سایت را آزمایش کنید

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

از کلاینتی شروع کنید که به سرویس نیاز دارد

پیش از آزمودن هر چیزی چهار مورد را بنویسید: نشانی کلاینت، نشانی مقصد، نام میزبان و پورت برنامه. سپس تأیید کنید که سرویس به‌صورت محلی در سایت خودش کار می‌کند، از میزبانی در کنار آن. بدون این خط پایه نمی‌توانید تونل خراب را از سرویس خراب تشخیص دهید، و نیمی از این تیکت‌ها همان دومی است.

نام میزبان مستند را امتحان کنید و جایی که سرویس اجازه می‌دهد، بررسی نشانی مستقیم همان پورت را. جست‌وجوی نامِ ناموفق و نشانی حل‌شده‌ای که در دسترس نیست شما را به مسیرهای متفاوتی می‌فرستند. اگر نام میزبان را با IP جایگزین کنید، بررسی هویت HTTPS را برای کار کردنش غیرفعال نکنید؛ هشدار گواهی اطلاعات است، نه مانع.

مسیر را در هر لبه طی کنید

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

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

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

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

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

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

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

شرایطی را که شکست می‌خورد بازتولید کنید

شکست‌هایی که فقط با انتقال‌های بزرگ ظاهر می‌شوند مسئله اندازه‌اند، نه اتصال. یک بسته بزرگ با بیت don't-fragment تنظیم‌شده بفرستید و ببینید کجا متوقف می‌شود. اگر درخواست کوچک موفق شود و درخواست بزرگ معلق بماند، MTU تونل و مدیریت MSS در دروازه‌ها مظنون‌های بعدی هستند.

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

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

پس از اصلاح، همان آزمایش را تکرار کنید

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

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