قانون دامنه VPN وقتی CDN نشانیهایش را عوض میکند میشکند
یک پاسخ DNS یک تصویر لحظهای است، نه فهرست کامل. سه شرط تعیین میکند که قانون مبتنی بر نام یا پیشوند صریح برای سرویس متکی به CDN مناسب است.
نشانی را از یک جستجو در قانون مسیریابی خود کپی میکنید، سایت کار میکند و یک هفته بعد کار نمیکند. هیچ چیز در قانون تغییر نکرده است. سرویس به نشانی لبه دیگری منتقل شده، کلاینت نام میزبان دیگری را حل کرده، یا نشست به IPv6 رفته است. تصمیمی که پیش روی شماست این است که آیا قانون مبتنی بر نام یا محدودهای صریح ابزار درست برای این سرویس است، و سه شرط آن را تعیین میکند. آنچه در پی میآید نام را از نشانی جدا میکند، چون تنها یکی از آن دو پایدار است.
چرا یک جستجو فهرست کامل نیست
یک شبکه توزیع محتوا با نشانیای پاسخ میدهد که برای حلکننده، منطقه و لحظه انتخاب شده است. دو بار از شبکههای مختلف بپرسید و ممکن است پاسخهای متفاوتی بگیرید. یک بار بپرسید و پاسخ را فهرست نشانیهای سرویس بدانید، و قانونی که مینویسید یک تصویر لحظهای است، نه یک قانون. این تمام مشکل برخورد با پاسخ DNS بهعنوان پیکربندی است.
شکاف دومی وجود دارد. یک نام میزبان قابل مشاهده بهندرت کل برنامه را پوشش میدهد، چون ورود، رسانه و ترافیک API اغلب از نامهای جداگانه استفاده میکنند. قانونی که از نام میزبان نوار نشانی ساخته شود میتواند صفحه را پوشش دهد و ویدیو را از دست بدهد، که بهعنوان شکست جزئی خوانده میشود، نه خطای مسیریابی.
شکاف سوم خانواده نشانی است. قانونی که فقط برای v4 است هیچ چیزی درباره رکورد AAAA که کلاینت ممکن است ترجیح دهد نمیگوید.
سه شرطی که بین قانون دامنه و محدودهها تصمیم میگیرد
نخست، آیا سرویس مجموعهای پایدار از پیشوندها را منتشر میکند که بتوانید مالک آن باشید و مستند کنید؟ اگر بله، محدودههای صریح صادقانه و ارزاناند. اگر نه، قانون دامنه تنها سازوکاری است که میتواند سرویس را دنبال کند.
دوم، آیا سازوکار دامنه کلاینت شما تازهسازی میشود؟ قانونی که یک بار هنگام اتصال حل میشود و دیگر هرگز، تصویری لحظهای با برندینگ بهتر است. سوم، آیا سازوکار زیردامنهها و هر دو خانواده نشانی را پوشش میدهد، یا فقط نامهایی که تایپ کردهاید؟
به آن سه پاسخ دهید و انتخاب معمولاً آشکار است. حدس زدن قانونی میسازد که در آزمایش کار میکند و در محیط عملیاتی شکست میخورد.
یک نشست را آزمایش کنید، نه یک صفحه
صفحه را بارگذاری کنید، سپس عملیاتی را انجام دهید که اهمیت دارد: وارد شوید، پخش را شروع کنید، فایلی را بارگذاری کنید. هر یک از اینها میتواند به میزبان متفاوتی برسد، و آنکه شکست میخورد همان است که قانون شما از دست داده.
فهرست کنید که نشست واقعاً با چه چیزی تماس میگیرد، نه آنچه صفحه نشان میدهد:
dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5حلکننده را در طول مقایسه قابل مشاهده نگه دارید، چون قانونی که از یک حلکننده کار میکند و از دیگری شکست میخورد درباره پاسخ CDN به شما میگوید، نه درباره تونل. TTL کوتاه همچنین یعنی پاسخی که ثبت کردهاید تاریخ انقضا دارد.
هر سازوکار واقعاً چه چیزی را پوشش میدهد
دو سازوکار در صفحه تنظیمات قابل تبادل به نظر میرسند و در زیر سطح متفاوت رفتار میکنند.
| Mechanism | What it matches | How it fails |
|---|---|---|
| Domain rule | Names the client resolves, then their addresses | Misses subdomains, or goes stale when refresh is off |
| Address route | A prefix you wrote down | Keeps matching an address the service has left |
مسیر نشانی در هسته پیشوندها را تطبیق میدهد. هیچ ایدهای ندارد که نام میزبان چیست، پس نمیتواند سرویسی را که نشانی عوض میکند دنبال کند. قانون دامنه نامها را حل و نتیجه را مسیریابی میکند؛ سرویس را دنبال میکند اما به حلکننده، رفتار تازهسازی و برخورد کلاینت با زیردامنهها وابسته است، پس قانونی که نامها را دنبال میکند باید با همان حلکنندهای آزمایش شود که کلاینت واقعاً به کار میبرد.
هیچکدام ابرمجموعه دیگری نیست، از این رو آمیختن آنها بدون یادداشت بعداً سردرگمی میآفریند.
پس از تغییر سرویس دوباره بررسی کنید
پس از بهروزرسانی کلاینت یا تغییر سرویس، همان آزمایش نشست را دوباره اجرا کنید. فهرست نشانیای که پیشتر کار میکرد شواهدی درباره آن دوره است، نه فهرست دائمی زیرساخت سرویس.
بنویسید کدام سازوکار کدام نام میزبان را پوشش میدهد، و تاریخ آخرین بررسی.
آن یادداشت تفاوت میان قانونی است که میتوانید از آن دفاع کنید و قانونی که هیچکس جرئت نمیکند به آن دست بزند. اگر سرویس فهرست پیشوندهای خودش را منتشر میکند، از آن استفاده کنید و تاریخ را ذکر کنید. اگر نه، این را بگویید، و قانون دامنه را با رفتار تازهسازیاش در کنارش نگه دارید.