یک قاعده سیاست، بسته‌های علامت‌خورده را به جدول اختصاصی می‌فرستد و انتظار معمول این است که از دست رفتن مسیر VPN آن‌ها را مسدود کند. سازوکار کار دیگری می‌کند. وقتی جدولی مسیر مطابق ندارد، جست‌وجو به قاعده بعدی ادامه می‌یابد به‌جای توقف، و جدول main هنوز یک مسیر پیش‌فرض معمولی برای uplink دارد. نتیجه پیکربندی‌ای است که fail-closed به نظر می‌رسد و fail-open رفتار می‌کند.

هیچ چیز خراب نیست؛ مسیریابی مبتنی بر سیاست این‌گونه تعریف شده است.

جست‌وجو وقتی جدول چیزی ندارد ادامه می‌یابد

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 lookup default
32766: from all lookup main

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

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

اقدام‌های پایانی جست‌وجو را پایان می‌دهند

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 prohibit
32766: from all lookup main

یک قاعده پایانی می‌تواند به‌جای جست‌وجو در جدول خالی، پس از جست‌وجوی VPN بیاید. با همان علامت، اقدام prohibit که پس از قاعده جدول 42 قرار می‌گیرد، وقتی آن جدول چیزی نمی‌دهد جست‌وجو را پایان می‌دهد و به‌جای دادن فرصتی دیگر به جدول main، یک رد اداری برمی‌گرداند. Unreachable و blackhole هم پایانی هستند، با رفتار خطای متفاوت برای فرستنده.

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

با علامت و رابط واقعی بررسی کنید

ip -4 rule show
ip -4 route show table 42
ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36

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

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

دو حالت خرابی، نه یکی

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

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

سیاست را جداگانه روی IPv6 اعمال کنید و استثناهای نقطه پایانی تأییدشده را صریح نگه دارید نه ضمنی.

مقالات مرتبط