مسیریابی سیاستی چه چیزی را در ترافیک VPN تغییر می‌دهد و چه چیزی را نه
قاعده‌ها تعیین می‌کنند کدام جدول بررسی شود، بنابراین مسیر پیش‌فرض در جدول اصلی غالباً چیزی را توضیح نمی‌دهد. پیش از افزودن قاعده، اولویت‌ها، نشانه‌ها و منابع را با هم بخوانید.
مسیریابی سیاستی به پرسشی متفاوت از آنچه بیشتر یادداشت‌های عیب‌یابی می‌پرسند پاسخ می‌دهد. جدول اصلی می‌گوید مقصد کجا می‌رود؛ قاعده‌های سیاستی می‌گویند اصلاً کدام جدول بررسی می‌شود، و می‌توانند این را بر اساس نشانی مبدأ، نشانهٔ بسته، یا رابطی که بسته از آن رسیده است تعیین کنند. وقتی یک تونل رفتاری ناسازگار دارد، مجموعهٔ قاعده‌ها غالباً دلیل است و جدول مسیریابی غالباً نه.
قاعده‌ها جدول را انتخاب می‌کنند، سپس جدول مسیر را انتخاب می‌کند
هر قاعده یک اولویت، یک شرط تطبیق و یک جدول هدف دارد. هسته قاعده‌ها را به ترتیب اولویت می‌پیماید و در نخستین تطبیق می‌ایستد، سپس جست‌وجوی متعارف طولانی‌ترین پیشوند را در آن جدول انجام می‌دهد. قاعده‌ای که به جدول خالی اشاره کند به آنچه قاعدهٔ بعدی انتخاب می‌کند می‌افتد، و این‌گونه است که یک قاعدهٔ دقیق نوشته‌شده می‌تواند بی‌اثر به نظر برسد.
به همین دلیل تخلیهٔ جدول اصلی به‌ندرت یک کلاینت VPN کارکننده را توضیح می‌دهد. کلاینت‌ها معمولاً قاعده‌ها را با شماره‌های اولویت پایین، بسیار پیش از قاعدهٔ پیش‌فرض جدول اصلی درج می‌کنند، پس بسته هرگز به مسیری که به آن خیره شده بودید نمی‌رسد. پایین آوردن یک متریک در جدول اصلی چیزی را برای ترافیکی که پیش‌تر منحرف شده است تغییر نمی‌دهد.
یک قاعده همچنین می‌تواند یک پیشوند را به‌عمد چاه سیاه یا دست‌نیافتنی کند. برخی کلاینت‌ها چنین قاعده‌ای را به‌عنوان کلید ایمنی اضافه می‌کنند، و آن‌گاه افت شبیه تونلی خراب به نظر می‌رسد نه تونلی پیکربندی‌شده.
مجموعهٔ قاعده‌ها را به‌صورت دنباله بخوانید، نه فهرست
قاعده‌ها را با اولویت‌هایشان و جدول‌هایی که به آن‌ها ارجاع می‌دهند چاپ کنید، سپس هر جدولی را که مسیر پیش‌فرض یا مسیر تونل دارد چاپ کنید. ترتیب همان بخشی است که اهمیت دارد، و همان بخشی است که تصویر صفحه معمولاً حذف می‌کند:
ip rule show ip route show table all | sed -n '1,60p' ip route get 198.51.100.20 from 10.8.0.2 ip route get 198.51.100.20 from 10.8.0.2 mark 0x1
دو فرمان آخر همان‌هایی هستند که نظریه را به مشاهده تبدیل می‌کنند، چون می‌پرسند هسته برای آن مبدأ و آن نشانه چه می‌کرد. اگر پاسخ با تغییر نشانه تغییر کند، قاعده‌ای مبتنی بر نشانه در کار است و هر آزمونی که نشانه را نادیده بگیرد بستهٔ دیگری را می‌آزماید. اتصال بیرونی سزاوار قاعدهٔ خودش است. تونلی که همهٔ ترافیک را از خودش مسیریابی می‌کند باید نشانی نقطهٔ پایانی‌ای را که به آن وصل می‌شود کنار بگذارد، وگرنه بسته‌های رمزنگاری‌شده به تونلی بازفرستاده می‌شوند که همین حالا ترکش کرده‌اند. بیشتر کلاینت‌ها این استثنا را خودکار درج می‌کنند، و مجموعهٔ قاعدهٔ دست‌ویرایش‌شده همان جایی است که این استثنا گم می‌شود.
نشانه‌ها و سوکت‌ها: دو شیوه‌ای که کلاینت‌ها ترافیک را تقسیم می‌کنند
برخی کلاینت‌ها بسته‌ها را در دیوار آتش نشانه می‌زنند و قاعده‌ای می‌افزایند که با نشانه تطبیق دارد. دیگران از مسیریابی در سطح سوکت استفاده می‌کنند و پیش از اتصال مسیری روی سوکت می‌گذارند. اولی در ip rule دیده می‌شود؛ دومی نه، و در یک جست‌وجوی عمومی ظاهر نمی‌شود.
اگر یک برنامهٔ آزمون رفتاری متفاوت از برنامه‌ای دارد که باید نمایندگی‌اش کند، بررسی کنید آیا برنامه نشانه می‌گذارد یا به دستگاهی می‌بندد. این تفاوت پس از نام‌گرفتن سازوکار دیگر راز نیست، و توضیح می‌دهد چرا curl از یک پوسته و یک زبانهٔ مرورگر می‌توانند روی یک ماشین مسیرهای متفاوت بگیرند. هر دو تکنیک به معنای گسترده مسیریابی سیاستی هستند: مسیر را با چیزی جز مقصد انتخاب می‌کنند. هیچ‌یک ترافیک را مجاز نمی‌کند، و هیچ‌یک جایگزین قاعده‌های دیوار آتش یا اعتبارنامه‌ای که همتا انتظار دارد نمی‌شود.
پیش از افزودن قاعدهٔ دیگر، مالکیت را ردیابی کنید
قاعده‌ها را چیزی نصب می‌کند. یک کلاینت VPN، یک مدیر شبکه و یک اسکریپت دست‌نویس هر یک می‌توانند هنگام راه‌اندازی قاعده اضافه کنند، و منطق اتصال دوباره می‌تواند مجموعهٔ پیشین را جا بگذارد. دو قاعدهٔ کهنه از یک پروفایل پیشین مدت‌ها پس از حذف پروفایل همچنان ترافیک را هدایت می‌کنند.
با اولویت و شکل قاعده پیدا کنید کدام فرایند مالک آن است، و بررسی کنید آیا آن مالک مجموعه را در هر اتصال بازنویسی می‌کند. اگر بکند، قاعدهٔ دستی‌ای که امروز افزوده شود فردا ناپدید می‌شود، و اصلاح به پیکربندی کلاینت تعلق دارد نه به پروندهٔ تاریخچهٔ پوسته. پاک کردن کل مجموعهٔ قاعده‌ها برای آزمون میان‌بری وسوسه‌انگیز با هزینهٔ قابل پیش‌بینی است: قاعده‌هایی را هم برمی‌دارد که کلاینت برای کار نگه داشتن تونل خودش لازم دارد. هر بار یک قاعده را حذف کنید، یا روی ماشینی بیازمایید که می‌توانید دوباره راه‌اندازی کنید.
دامنه را با دو جریان اثبات کنید، نه یکی
یک اصلاح فقط با جریانی که باید تحت تأثیر قرار گیرد و جریانی که نباید، تأیید می‌شود. مقصدی را انتخاب کنید که سیاست آن را به تونل می‌فرستد، و مقصدی که باید بیرون بماند، سپس جست‌وجوها و ضبط‌ها را برای هر دو مقایسه کنید:
ip route get 198.51.100.20 from 192.0.2.44 ip route get 198.51.100.21 from 192.0.2.44 tcpdump -ni any host 198.51.100.21 and port 443
وقتی دو جست‌وجو رابط‌های متفاوت برمی‌گردانند، قاعده کاری می‌کند. وقتی همان رابط را برمی‌گردانند، قاعده گسترده‌تر از مقصود تطبیق می‌کند، و این همان خرابی‌ای است که بی‌صدا یک زیرشبکهٔ کامل را از تونلی می‌فرستد که برای یک برنامه در نظر گرفته شده بود.
اولویت‌های قاعده‌ها و سرویس مالک را همراه با دو نشانی آزمون در تیکت ثبت کنید. آن‌گاه نفر بعدی به‌جای توصیف یک نشانه، جفتی تکرارپذیر دارد و می‌تواند در یک دقیقه بگوید آیا مسیریابی سیاستی هنوز در کار است.