مسیریابی VPN مبتنی بر دامنه در برابر مسیرهای IP: کدام مناسب است؟
نام میزبان در جعبه تونل تقسیم‌شده یک مسیر نیست. قواعد دامنه و پیشوندهای صریح را از نظر به‌روزرسانی، گستره زیردامنه‌ها و آنچه هنگام تغییر DNS رخ می‌دهد مقایسه کنید.
یک مسیر IP با پیشوند آدرس مطابقت دارد و هسته آن را بدون پرسیدن سؤال بیشتری اعمال می‌کند. یک قاعده VPN مبتنی بر دامنه با یک نام مطابقت دارد، یعنی چیزی در پشته باید تصمیم بگیرد که آن نام در حال حاضر به کدام آدرس‌ها اشاره دارد و آن تصمیم را به‌روز نگه دارد. این‌ها سازوکارهای متفاوتی با حالت‌های خرابی متفاوت هستند و فروشندگان برای هر دو از یک واژه استفاده می‌کنند. مقایسه آن‌ها در فهرست ویژگی‌ها اصل مطلب را از دست می‌دهد؛ آن‌ها را بر اساس آنچه هنگام تغییر پاسخ رخ می‌دهد مقایسه کنید.
تقسیم مفید میان قاعده‌ای است که تفکیک می‌کند و قاعده‌ای که تفکیک نمی‌کند.
هر قاعده واقعاً با چه چیزی مطابقت دارد
یک قاعده پیشوند با آدرس‌های مقصد در جدول مسیریابی مطابقت دارد. هیچ چیز تفکیک نمی‌شود، هیچ چیز منقضی نمی‌شود و تطابق برای هر بسته دقیق است. یک قاعده دامنه با درخواست یک برنامه برای یک نام مطابقت دارد، که RFC 1034 آن را درختی از برچسب‌ها و نه یک آدرس تعریف می‌کند. برخی محصولات نام را یک بار تفکیک می‌کنند و آدرس‌های حاصل را به‌عنوان مسیر نصب می‌کنند، که قاعده را به یک قاعده IP با یک زمان‌سنج به‌روزرسانی ضمیمه تبدیل می‌کند.
پیش از عیب‌یابی بدانید کدام یک از این دو را دارید، چون خرابی در هر حالت کاملاً متفاوت به نظر می‌رسد.
قاعده دامنه کجای پشته قرار دارد
اگر محصول قواعد دامنه را از طریق یک پروکسی محلی پیاده‌سازی کند، ترافیک باید به آن پروکسی برسد و برنامه‌هایی که پروکسی سیستم را نادیده می‌گیرند کاملاً از قاعده عبور می‌کنند. اگر آن‌ها را با تفکیک نام‌ها و افزودن مسیرها پیاده‌سازی کند، آدرس‌ها تنها به اندازه آخرین به‌روزرسانی تازه هستند. اگر به تفکیک‌کننده قلاب بزند، رفتار DNS بخشی از سیاست مسیریابی می‌شود و یک تفکیک‌کننده پشتیبان می‌تواند بی‌صدا آن را باطل کند.
مدل فروشنده را بخوانید، نه برچسب تنظیمات را. دو کلاینت با جعبه‌ای به نام Split Tunnel می‌توانند سه کار متفاوت انجام دهند.
مقایسه کنید چه چیزی می‌شکند
سه چیز به شکل‌های متفاوت می‌شکند. تغییر آدرس‌ها: یک نام میزبان CDN می‌تواند در عرض چند دقیقه به مجموعه آدرس متفاوتی تفکیک شود، پس فهرست کپی‌شده به‌سرعت کهنه می‌شود. گستره زیردامنه: قاعده‌ای برای example.com ممکن است api.example.com را پوشش بدهد یا ندهد و مستندات معمولاً صریح می‌گوید کدام است. شکست تفکیک: وقتی تفکیک‌کننده شکست می‌خورد، کلاینتی که تفکیک می‌کند ممکن است به تونل‌کردن ترافیک یا به ارسال مستقیم آن بازگردد.
تنها دومی یک پرسش پیکربندی است. دو مورد دیگر پرسش‌های طراحی درباره این هستند که محصول چقدر حاضر است حدس بزند.
| Behaviour | Prefix rule | Domain rule |
|---|---|---|
| Match basis | destination address | requested name or resolved addresses |
| Staleness | none | depends on refresh policy |
| Subdomain scope | not applicable | product-defined |
| Resolver outage | unaffected | product-defined fallback |
| Where to debug | routing table | client log plus resolver state |
چه زمانی پیشوند پاسخ بهتر است
برای یک زیرشبکه خصوصی پایدار، پیشوند صریح روشن‌تر، سریع‌تر و آسان‌تر برای حسابرسی است. از قطعی تفکیک‌کننده هم جان سالم به در می‌برد، چون هیچ چیز نباید تفکیک شود. وقتی سرویس میزبانی می‌شود، وقتی آدرس‌ها می‌چرخند یا وقتی واقعاً نمی‌توانید مجموعه مقصد را برشمارید، به سراغ قاعده دامنه بروید. فقط به این دلیل که نام میزبان چیزی است که تصادفاً می‌دانید، به سراغش نروید.
فهرست ایستای حدس‌زده‌شده بدترین هر دو است: نگه‌داری‌شده به نظر می‌رسد و روزی که ارائه‌دهنده میزبانی اضافه می‌کند، بی‌صدا ترافیک را از دست می‌دهد.
با یک درخواست تازه بررسی کنید
پس از یک اتصال مجدد عادی با درخواست سرد آزمایش کنید، چون صفحه ذخیره‌شده در حافظه نهان ممکن است هرگز قاعده را لمس نکند. نام را تفکیک کنید، سپس بررسی کنید اتصال واقعاً کجا رفته است. dig +short app.example.com مجموعه آدرس فعلی را می‌دهد و فهرست اتصال‌های کلاینت به شما می‌گوید کدام رابط جریان را حمل کرده است.
پس از فاصله به‌روزرسانی که محصول مستند می‌کند تکرار کنید. اگر مجموعه آدرس جابه‌جا شود و قاعده آن را دنبال نکند، رفتار واقعی را پیدا کرده‌اید.
سیاست تفکیک‌کننده را هم جدا نگه دارید. قاعده دامنه به داده نام درست نیاز دارد، اما به‌تنهایی تصمیم نمی‌گیرد کدام تفکیک‌کننده به پرس‌وجو پاسخ می‌دهد.