Linux EHOSTUNREACH با OpenVPN: کدام گام بعدی شکست خورد؟

EHOSTUNREACH به همان اندازه که یک شکست دور است، یک تصمیم محلی است. هسته می‌تواند بسته‌ای را رد کند چون مسیری می‌گوید مقصد غیرقابل‌دسترس است، چون گام بعدی Ethernet هرگز پاسخ نداد، یا چون گزارش ICMP host-unreachable از جایی دورتر در مسیر رسیده است. هر منبع در جدول یا حافظه‌ی نهان متفاوتی زندگی می‌کند و هر کدام جای متفاوتی اصلاح می‌شود. پیش از دست زدن به رمزها یا نصب دوباره‌ی تونل، مسیر انتخاب‌شده و وضعیت گام بعدی را بخوانید.

نشانی و فضای نامی را انتخاب کنید که کارخواه واقعاً استفاده می‌کند

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

جست‌وجو باید همان بافت منبع، نشانه و جدول برنامه‌ی شکست‌خورده را به کار ببرد، وگرنه ممکن است به پرسشی پاسخ دهد که کسی نپرسیده است. برای یک همتای IPv4 نمونه، بررسی‌های فقط‌خواندنی این‌ها هستند:

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

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

یک مسیر صریحاً غیرقابل‌دسترس بسته را به‌صورت محلی رد می‌کند

مسیری از نوع unreachable پاسخی محلی و عمدی است. به هسته می‌گوید بسته را دور بریزد و EHOSTUNREACH را به فرستنده برگرداند، از همین رو خطا فوراً و بدون هیچ ترافیکی که ماشین را ترک کند ظاهر می‌شود. کسی یا خودکاری آن مسیر را عمداً آنجا گذاشته است.

انواع مسیر قابل‌جایگزینی نیستند. Blackhole بسته را بدون خطا به فرستنده دور می‌ریزد، prohibit کد EACCES را برمی‌گرداند و unreachable کد EHOSTUNREACH را. بنابراین یک کمک‌کننده‌ی VPN که هنگام اتصال دوباره مسیر چاهک نصب می‌کند می‌تواند انبوهی از خطاهای host-unreachable تولید کند که با بالا آمدن تونل ناپدید می‌شوند، در حالی که مسیر blackhole به‌جای آن مهلت‌های خاموش تولید می‌کرد.

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

همسایه‌ی مرده همان خطا را روی Ethernet تولید می‌کند

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

جدول همسایه مرحله را نام می‌برد. INCOMPLETE یعنی حل هنوز در جریان است، FAILED یعنی آخرین تلاش پاسخی نگرفت، و REACHABLE یا STALE یعنی هسته نشانی قابل‌استفاده دارد. ورودی FAILED برای دروازه‌ی VPN یک مشکل تحویل محلی است، نه شاهدی درباره‌ی طرف دور تونل.

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

گزارش‌های دور و خطاهای ناهمگام UDP

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

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

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

پیش از تغییر رمزنگاری لایه‌ها را جدا کنید

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

مشکلات احراز هویت و مذاکره پس از رسیدن انتقال به همتا به‌صورت خطاهای خودشان ظاهر می‌شوند. تغییر یک رمز یا نصب دوباره‌ی کارخواه نمی‌تواند مسیر unreachable محلی را درست کند و شواهد مسیر و همسایه را که برای علت واقعی لازم دارید نابود می‌کند.

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