UDR در Azure به دروازه VPN: یک مقصد، نه تمام ترافیک خروجی

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

گام بعدی یک دروازه است، نه IP یک دستگاه

یک UDR پیشوند منطبق را به یک نوع گام بعدی می‌فرستد و VirtualNetworkGateway یک نوع است، نه یک آدرس. افراد IP خصوصی دروازه را در یک مسیر VirtualAppliance می‌چسبانند و بعد می‌پرسند چرا هیچ‌چیز منطبق نیست، چون آن نوع در عوض یک NIC یا یک متعادل‌کننده بار داخلی انتظار دارد. مستندات مسیریابی مایکروسافت نیز گام بعدی دروازه را به شبکه مجازی محدود می‌کند که دروازه آن یک دروازه VPN است. ExpressRoute، Route Server و یک هاب Virtual WAN با آن گزینه آدرس‌دهی نمی‌شوند.

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

پیش از هر تغییری مسیر مؤثر را بخوانید

Azure مسیرهای سیستمی، پیشوندهای آموخته‌شده از BGP و UDRها را در یک جدول مسیر مؤثر برای هر NIC ترکیب می‌کند و بلندترین پیشوند منطبق برنده است، مهم نیست از کجا آمده باشد. برای یک پیشوند یکسان، یک UDR بر یک مسیر BGP پیروز می‌شود. همین ترتیب دلیل آن است که یک UDR قدیمی از آزمایشی پیشین می‌تواند بی‌صدا بر پیشوندی که تازه از طریق تونل آموخته‌اید چیره شود.

ابتدا جدول مؤثر را ببینید، سپس تصمیم بگیرید مسیر اضافه می‌کنید یا یکی را جایگزین می‌کنید:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

ستون منبع را هم بخوانید، نه فقط پیشوند را. مسیری با پیشوند درست و منبع نادرست به شما می‌گوید کدام شیء را ویرایش کنید و شما را از افزودن مسیر دومی که به مسیر اول می‌بازد نجات می‌دهد.

مسیر را بر اساس پیشوند و زیرشبکه واقعی بنویسید

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

مسیر را بسازید، سپس جدول را به زیرشبکه‌ای که بار کاری را میزبانی می‌کند پیوند دهید:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

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

نیمه محلی را تمام کنید وگرنه جریان همان‌جا می‌میرد

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

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

انتخابگرها و فهرست‌های مجاز جدا از همه اینها هستند. انتخاب یک گام بعدی Azure انتخابگرهای ترافیک VPN را گسترده نمی‌کند و فهرست مجاز منبع یک سرویس خارجی را تغییر نمی‌دهد.

با منبعی که مقصد مشاهده می‌کند بررسی کنید

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

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