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

با شمردن قواعدی که نگه می‌دارید شروع کنید

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

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

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

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

تونل کامل هر بسته را به یک دستگاه می‌برد، که هم‌زمان بار پردازنده آن دستگاه، جدول conntrack، ترجمه نشانی و نیاز به پهنای باند بالادست را تغییر می‌دهد. دروازه‌ای که با آسودگی چند زیرشبکه داخلی را سرو می‌کرد شاید برای تمام مرور یک کاربر اندازه‌گیری نشده باشد. به بزرگ‌ترین شمار نشست‌های هم‌زمانی که انتظار دارید نگاه کنید نه به میانگین، زیرا قله است که نخست می‌شکند.

ip -s link show dev tun0
conntrack -C
ss -s

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

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

تأیید کنید که سرویس‌های محلی و DNS خصوصی هنوز کار می‌کنند

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

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

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

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

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

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

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

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

مقالات مرتبط