چرا ماشین مجازی با دستگاه VPN در Azure مسیر بازگشت را از دست می‌دهد
دستگاه VPN در یک ماشین مجازی Azure نیاز دارد که UDR، پرچم ارسال مجدد کارت شبکه و سیاست مهمان با هم هماهنگ باشند. یک درخواست شعبه را از میان هر سه دنبال کنید.
ماشین مجازی Azure که یک دستگاه VPN را اجرا می‌کند، درون دو سیستم تصمیم‌گیری مستقل قرار دارد. Azure تصمیم می‌گیرد بسته از کجای زیرشبکه خارج می‌شود، با استفاده از جدول‌های مسیر و تنظیم ارسال مجدد کارت شبکه. سیستم‌عامل خود دستگاه تصمیم می‌گیرد که بسته رمزگشایی‌شده را جلوتر بفرستد یا نه. تونلی که بی‌عیب بالا می‌آید باز هم می‌تواند در سیستم دوم شکست بخورد، و بیشتر این استقرارها همان‌جا متوقف می‌شوند.
سه مالک یک مسیر
یک شبکه شعبه بگیرید 192.168.50.0/24 و یک زیرشبکه بار کاری 10.0.10.0/24، با دستگاه در 10.0.0.4 در زیرشبکه خودش. یک درخواست تنها سه پیکربندی جداگانه را لمس می‌کند.
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
هر سطر در بیشتر سازمان‌ها مالک تیم متفاوتی است، و به همین دلیل این خرابی معمولاً به‌جای یک تیکت در قالب سه تیکت می‌رسد.
مسیری که به دستگاه اشاره می‌کند
یک جدول مسیر را به زیرشبکه بار کاری متصل کنید و به پیشوند شعبه یک گام بعدی از نوع Virtual appliance با 10.0.0.4 به‌عنوان آدرس بدهید. از آدرس خصوصی در دسترس دستگاه استفاده کنید، هرگز نقطه ورود عمومی VPN آن. گام بعدی باید آدرسی باشد که زیرشبکه بار کاری از قبل می‌تواند به آن برسد. بقیه مسیریابی بار کاری را رها کنید مگر اینکه آگاهانه تصمیم گرفته باشید مسیر پیش‌فرض را جایگزین کنید.
دستگاه را در زیرشبکه خودش نگه دارید و مطمئن شوید مسیری که ترافیک شعبه را به دستگاه می‌فرستد مسیر خروجی خود دستگاه را هم نمی‌گیرد. چنین حلقه‌ای مانند یک تونل سالم با صفر پاسخ به نظر می‌رسد، و این چیز بسیار ناخوشایندی برای عیب‌یابی در ساعت 2 بامداد است.
پرچم کارت شبکه که همه فراموش می‌کنند
Azure برای هر کارت شبکه یک تنظیم ارسال مجدد IP دارد و به‌طور پیش‌فرض خاموش است. این تنظیم وجود دارد چون کارت شبکه‌ای که ارسال مجدد می‌کند بسته‌هایی دریافت می‌کند که به چیز دیگری آدرس‌دهی شده‌اند، و دور ریختن خاموش آن‌ها پیش‌فرض ایمن برای بقیه است.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true آن را برای یک رابط روشن می‌کند. راهنمای Microsoft درباره ارسال مجدد در کارت شبکه این تنظیم را روی هر کارت شبکه متصل که ترافیک را ارسال مجدد می‌کند لازم می‌داند، پس دستگاه تک‌کارت هم باید آن را روی همان کارت تنظیم کند.
این پرچم یک مسیر نیست و یک قاعده فایروال هم نیست. روشن کردنش اجازه می‌دهد و هیچ چیز دیگری.
مهمان با بسته رمزگشایی‌شده چه می‌کند
وقتی تونل پایان می‌یابد، پشته خود دستگاه تصمیم بعدی را می‌گیرد. روی مهمان Linux، ارسال مجدد IPv4 یک تنظیم زمان اجراست، و sysctl -w net.ipv4.ip_forward=1 تا بوت بعدی دوام می‌آورد. آن را به‌جای این در فایلی زیر /etc/sysctl.d/ ذخیره کنید. دستگاه یک فروشنده معادل خودش را دارد، و دستورهای Linux که در بستر یک فروشنده چسبانده شوند معمولاً هیچ کاری نمی‌کنند.
سیاست فایروال مهمان باز هم جداست، و همچنین گروه امنیت شبکه بار کاری. اجازه دادن UDP 500 و 4500 به آدرس عمومی ماشین مجازی از تونل محافظت می‌کند؛ اما هیچ چیزی درباره اینکه یک درخواست شعبه رمزگشایی‌شده می‌تواند به یک پورت بار کاری برسد نمی‌گوید.
یک درخواست و پاسخش را دنبال کنید
یک جریان مجاز انتخاب کنید و آن را سرتاسر دنبال کنید. شعبه به یک مسیر نیاز دارد برای 10.0.10.0/24 از طریق اتصال سایت، دستگاه به مسیر تحویل به زیرشبکه بار کاری نیاز دارد، و زیرشبکه بار کاری به یک مسیر بازگشت به سمت شعبه نیاز دارد.
زود تصمیم بگیرید که طراحی آدرس مبدأ شعبه را حفظ می‌کند یا آن را ترجمه می‌کند. NAT آنچه بار کاری می‌بیند را تغییر می‌دهد، پس قواعد دسترسی آن باید مدلی را توصیف کنند که واقعاً انتخاب کرده‌اید، نه یک آدرس دروازه حدسی.
یک دست‌دهی موفق یک حلقه از آن زنجیره را اثبات می‌کند. مسیر زمانی کامل است که پاسخ از همان دستگاه برگردد و سیاست خود بار کاری آن را اجازه دهد.