RRAS روی Azure VM پشتیبانی نمی‌شود: پیش از طراحی بررسی کنید

پورتال را باز می‌کنید، Windows Server 2022 را در یک زیرشبکه مستقر می‌کنید و نقش Remote Access بی‌دردسر نصب می‌شود. این توالی ثابت می‌کند که نصب‌کننده کار می‌کند، نه اینکه مایکروسافت این پیکربندی را پشتیبانی کند. راهنمای منتشرشده پشتیبانی نرم‌افزار سرور برای ماشین‌های مجازی Azure، RRAS را در شمار قابلیت‌های Windows Server قرار می‌دهد که روی Azure VM پشتیبانی نمی‌شوند، و این تصمیمی معماری است نه جزئیاتی از عیب‌یابی. تونلی که بالا می‌آید استقرار را به داخل مرز پشتیبانی نمی‌برد.

راهنمای زیر از صفحه پشتیبانی آغاز می‌شود و سپس به سمت الزامات و گزینه‌های جایگزینی گسترش می‌یابد.

از صفحه پشتیبانی شروع کنید، نه از آزمایشگاه

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

تا صفحه باز است، استناد را در سند طراحی بنویسید. وضعیت پشتیبانی واقعیتی با منبع است و بازبینی طراحی‌ای که نتواند به آن استناد کند، توسط کسی که دمو را دارد از اعتبار می‌افتد.

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

همین راهنما Network Policy and Access Services را در زمره نقش‌های پشتیبانی‌شده می‌آورد، در حالی که RRAS را جداگانه پشتیبانی‌نشده می‌داند. این دو مدخل چیزهای متفاوتی را توصیف می‌کنند و ادغام آن‌ها در «دسترسی از راه دور پشتیبانی می‌شود» راهی است که یک پروژه بر پایه بدخوانی تأیید می‌شود. پشتیبانی‌شدن سیستم‌عامل چیزی درباره قابلیتی که ردیف خودش را دارد نمی‌گوید.

این محدودیت از آنچه گاهی نقل می‌شود تنگ‌تر است. موضوع آن قابلیتی است که داخل یک Azure VM اجرا می‌شود؛ به این معنا نیست که شبکه خصوصی نمی‌تواند به Azure متصل شود و نمی‌گوید RRAS هیچ‌جا پشتیبانی نمی‌شود. آزمایشگاه قدیمی‌ای که بسته‌ها را درست هدایت می‌کند شاهدی درباره بسته‌ها است، نه درباره بیانیه پشتیبانی.

این دو پرسش را در ادامه پروژه جدا نگه دارید: آیا کار می‌کند و آیا پشتیبانی می‌شود. برای هرکدام پاسخ‌های متفاوت و گاهی مالکان متفاوت لازم خواهید داشت.

بنویسید طراحی واقعاً باید چه کار کند

پیش از انتخاب جایگزین، فهرست سایت‌ها را به الزاماتی تبدیل کنید که یک محصول را بتوان با آن‌ها سنجید:

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

NAT همان موردی است که نادیده گرفته می‌شود و بعد کل طراحی را تعیین می‌کند. دستگاهی که می‌تواند IPsec برقرار کند ممکن است نشانی‌ها را متفاوت از استقرار RRASی که جایگزینش می‌شود ترجمه کند، و این تغییر می‌دهد که شعبه چه چیزی را به‌عنوان نشانی مبدأ می‌بیند و گزارش‌های شما چه ثبت می‌کنند.

فهرست را به مالکان شبکه ببرید و پیش از هر بحث محصولی تأییدش کنید. الزامات مبهم هر مقایسه فروشنده را به جدال سلیقه تبدیل می‌کنند.

جایگزین‌ها را با همین الزامات بسنجید

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

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

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

اگر RRAS VM از قبل در حال اجراست

کشف دلیل حذف آن نیست. تغییر را حول وابستگی‌هایی برنامه‌ریزی کنید که آن VM انباشته است: مسیرهایی که زیرشبکه‌های دیگر به آن‌ها تکیه دارند، قواعد NAT که نشانی‌های مبدأ را پنهان می‌کنند، و هر چیزی که پایش آموخته از نشانی آن انتظار داشته باشد. مسیرهای لازم و یک مسیر بازیابی آزموده‌شده را حفظ کنید تا وقتی هدف پشتیبانی‌شده در کنارش طراحی و اعتبارسنجی می‌شود.

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

راهنما را با ثبت استناد پشتیبانی، فهرست الزامات، جایگزین برگزیده و ترتیب مهاجرت ببندید. این چهار مورد اولین چیزی است که یک بازرس یا عضو جدید تیم می‌پرسد.