ExpressRoute به‌همراه VPN: کدام دامنه‌های خرابی را پوشش می‌دهید؟
یک تونل دوم IPsec یک نقطه پایانی را پوشش می‌دهد، نه مدار زیر آن را. هر دامنه خرابی را نقشه کنید، سپس تصمیم بگیرید آیا مسیر جایگزین بدون رمزنگاری مجاز است.
تونل IPsec که روی peering خصوصی ExpressRoute اجرا می‌شود، رمزنگاری را به انتقالی که از قبل وجود دارد اضافه می‌کند. تونل دوم دسترس‌پذیری نقطه پایانی را بهبود می‌دهد و برای مسیر اپراتور در زیر هر دو هیچ کاری نمی‌کند. وقتی داشبوردها دو تونل سبز را نشان می‌دهند و بازبینی طراحی پرسش دیگری می‌پرسد، این تمایز به‌سادگی از دست می‌رود: این اتصال باید از کدام خرابی‌ها جان سالم به در ببرد؟ نخست به آن پاسخ دهید، سپس تونل‌ها را بشمارید، زیرا تعداد نشانگرهای سبز ویژگی لایه رمزنگاری است و تعداد دامنه‌های خرابی ویژگی کل مسیر است.
با خرابی‌ها شروع کنید، نه با تونل‌های سبز
پیش از ترسیم هر چیزی چهار سطر بنویسید: خرابی یک نقطه پایانی VPN یا یک نمونه همتا، خرابی یک روتر محلی یا اتصال مایل اول، خرابی مسیر مشترک ExpressRoute، و در دسترس نبودن IPsec در حالی که peering خصوصی هنوز ترافیک را حمل می‌کند. هر سطر نام می‌برد که طراحی باید چه چیزی را حفظ کند، و به هر یک مکانیزم متفاوتی پاسخ می‌دهد.
| Failure | What must survive | What does not cover it |
|---|---|---|
| One VPN endpoint or instance | An alternate encryption endpoint and a route to it | A second tunnel terminating on the same instance |
| One local router or first mile | Independent local equipment and transport reachability | Any number of logical tunnels |
| The ExpressRoute path | A separately designed surviving underlay | An IPsec tunnel layered on the same circuit |
| IPsec unavailable, peering up | The intended encrypted-only or approved fallback policy | Assuming the tunnel is the only route |
Microsoft آیین‌نامه VPN سایت به سایت با IP خصوصی روی peering خصوصی ExpressRoute و همزیستی پشتیبانی‌شده با اتصال‌های سایت به سایت مبتنی بر اینترنت را مستند می‌کند. آن همزیستی طراحی متفاوتی برای لایه زیرین است و صرفاً به این دلیل که نقطه پایانی تونل خصوصی دیگری اضافه کرده‌اید پدید نمی‌آید.
دامنه خرابی 1: نقطه پایانی VPN
دو تونل روی یک دروازه معمولاً جفت‌های active-active هستند که روی همان منبع سمت Azure پایان می‌یابند. آن‌ها از مشکل یک تونل یا یک نمونه محافظت می‌کنند و از در دسترس نبودن، پیکربندی مجدد یا تمام شدن ظرفیت آن منبع محافظت نمی‌کنند. افزونگی نقطه پایانی یعنی نقطه پایانی دوم پشتیبانی‌شده، با مسیر خودش و پیکربندی خودش، به‌همراه مسیری که بتواند به آن برسد.
بررسی کنید که واقعاً چه چیزی مستقر کرده‌اید، نه آنچه نمودار می‌گوید، زیرا پورتال این منابع را به گونه‌ای گروه‌بندی می‌کند که رابطه آن‌ها را پنهان می‌کند:
az network vpn-connection show -g rg-connectivity -n vpn-to-hub --query '{conn:connectionStatus,tunnels:tunnelConnectionStatus}'
az network vnet-gateway show -g rg-connectivity -n gw-hub --query '{sku:sku.name,activeActive:enableBgp,peers:bgpSettings.peers}'اگر هر دو تونل به یک دروازه با یک IP عمومی اشاره کنند، افزونگی نقطه پایانی از نوعی مشخص و محدود دارید. ممکن است دقیقاً همان چیزی باشد که نیازمندی می‌خواهد، و باید همان‌گونه بیان شود نه اینکه به‌عنوان یک اتصال افزونه توصیف شود.
دامنه خرابی 2: مسیر محلی و اپراتور
در زیر رمزنگاری، واقعیتی فیزیکی و تجاری قرار دارد: دستگاه لبه مشتری، یک اتصال متقاطع، شبکه ارائه‌دهنده و یک مکان peering. راهنمای دسترس‌پذیری ExpressRoute صریح می‌گوید که افزونگی سرتاسری شامل بخش‌های مشتری و ارائه‌دهنده سرویس است، نه فقط سمت Microsoft. دو مسیر منطقی که یک روتر، یک منبع تغذیه یا یک اتصال مایل اول را به اشتراک می‌گذارند، هنوز همان وابستگی را به اشتراک می‌گذارند.
اینجاست که یک طراحی معمولاً در بازبینی صادقانه مردود می‌شود. دو مدار از یک ارائه‌دهنده، که در یک ساختمان پایان می‌یابند، روی تجهیزاتی از یک سفارش خرید، دو دامنه خرابی نیستند. آن‌ها یک دامنه خرابی با دو صورت‌حساب هستند.
پرسش اپراتور را کتبی بپرسید: کدام یک از این مسیرها واگرا می‌شوند، کجا، و رفتار مستند هنگام خرابی بخش مشترک چیست؟ اطمینان شفاهی در یک تماس طراحی، از قطعی که برای آن طراحی می‌کنید جان سالم به در نمی‌برد.
دامنه خرابی 3: مسیری که بدون IPsec باقی می‌ماند
peering خصوصی و IPsec می‌توانند مسیرهای رقیب به همان پیشوند برنامه ارائه دهند. اگر مسیر محافظت‌شده ناپدید شود، یک مسیر مستقیم ExpressRoute که باقی مانده ممکن است هنوز قابل استفاده باشد، بدون لایه رمزنگاری که تونل فراهم می‌کرد. اینکه آیا این پذیرفتنی است یک تصمیم سیاستی است، و همان تصمیمی است که بیشتر از همه ضمنی رها می‌شود.
الزامات رمزنگاری و الزامات دسترس‌پذیری می‌توانند اینجا واقعاً با هم تعارض پیدا کنند. «هر مسیری که باقی بماند موفقیت شمرده می‌شود» یک گزاره دسترس‌پذیری است که بی‌صدا به پرسش رمزنگاری «نه» پاسخ می‌دهد. بنویسید کدام یک برنده است، برای کدام پیشوندها، و چه کسی آن را تأیید کرده است.
az network vnet-gateway list-advertised-routes -g rg-connectivity -n gw-hub --peer 10.0.0.1
az network vnet-gateway list-learned-routes -g rg-connectivity -n gw-hub -o tableمسیرهای آموخته‌شده را با پیشوندهایی که انتظار داشتید مقایسه کنید. یک مسیر جایگزین که بار مدیریتی کوچکی را حمل می‌کند ممکن است برای آن بار کاملاً کافی باشد و از ظرفیتی که تقاضای تولید نیاز دارد بسیار دور باشد، پس فرض ظرفیت را در کنار مسیر ثبت کنید.
سه سطر جداگانه ثبت کنید، نه یک حکم واحد
افزونگی نقطه پایانی، افزونگی انتقال و بازیابی پس از فاجعه را به‌عنوان ورودی‌های جداگانه در سند طراحی نگه دارید، هر یک با مکانیزم، بررسی و مالک خودش. وقتی بازبینی یک حادثه می‌پرسد چرا اتصال از راه‌اندازی مجدد دروازه جان سالم به در برد اما از برش فیبر نه، سه سطر در یک جمله پاسخ می‌دهند؛ یک کادر «افزونه» نمی‌تواند.
سپس سطرهایی را که ارزان می‌توان آزمایش کرد بیازمایید. یک تونل را از کار بیندازید و تأیید کنید که ترافیک جابه‌جا می‌شود و دوباره رمزنگاری می‌شود. یک مسیر را پس بگیرید و تأیید کنید که مسیر باقی‌مانده همانی است که در نظر داشتید، سپس تأیید کنید که آیا هنوز رمزنگاری‌شده است. خرابی‌هایی را که نتوانستید شبیه‌سازی کنید مستند کنید، زیرا سطر آزمایش‌نشده یک فرض است و باید چنین برچسب بخورد.
خروجی مفید یک جدول کوتاه به‌همراه یک جمله برای هر سطر است. اگر سطری مکانیزم نداشته باشد، همان یافته است، و کشف آن در بازبینی طراحی بسیار ارزان‌تر از کشف آن در زمان قطعی اپراتور است که هیچ‌یک از دو تونل هرگز از آن جان سالم به در نمی‌برد.