ماشین مجازی Azure پس از روشن شدن VPN به IMDS یا WireServer نمی‌رسد

ماشین روشن است، کلاینت VPN می‌گوید متصل است و چند دقیقه بعد عامل Azure شروع به گزارش ناسالمی می‌کند. گاهی SSH باقی می‌ماند و Run Command پورتال کار نمی‌کند، و همین مردم را به سراغ عامل به جای جدول مسیر می‌فرستد. تصمیم‌های هدایت خود مهمان با بالا آمدن تونل تغییر کرد و دو نشانی پلتفرم معمولاً اولین قربانی‌ها هستند. من این را پیش از آنکه خرابی عامل بدانم، نشانه‌ای از مسیریابی می‌دانم.

نشانه شبیه عامل خراب است

هر دو نشانی زیر به‌عنوان راه‌حل پیشنهاد می‌شوند، در حالی که یک سرویس نیستند. کپی کردن یک /32 برای یکی چون برای دیگری کار کرد، دقیقاً همان راهی است که یک راه‌حل موقت به پیکربندی دائمی تبدیل می‌شود که کسی جرئت حذفش را ندارد.

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

168.63.129.16 مقصد عمومی نیست

168.63.129.16 نشانی مجازی ویژه پلتفرم Azure است و یکی از نقش‌هایش WireServer است که عامل ماشین برای گفتگو با فابریک از آن استفاده می‌کند. مایکروسافت مستند کرده است که ترافیک عامل به پورت‌های TCP 80 و 32526 باید در دسترس بماند. این یک میزبان معمولی اینترنت نیست و چیزی نیست که VPN تمام‌تونل آن را به خروجی راه دور ببرد. به همین دلیل تونلی که سالم به نظر می‌رسد باز هم می‌تواند عامل را گرسنه بگذارد.

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

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

169.254.169.254 قواعد خودش را دارد

169.254.169.254 نشانی link-local سرویس Azure Instance Metadata Service است. درخواست‌ها به آن الزامات خودش را دارند: کارت شبکه اصلی و IP اصلی، پیکربندی DHCP که نشانی را پشتیبانی کند، و دور زدن هر پروکسی HTTP. فرستادن آن‌ها از خروجی VPN راه دور یا دروازه اینترنت دلبخواه، مدل دسترسی‌ای نیست که مایکروسافت توصیف می‌کند.

این بند پروکسی کسانی را می‌گیرد که مسیر را درست کرده‌اند و هنوز خطا می‌بینند. پروکسی HTTP در مهمان می‌تواند IMDS را بشکند در حالی که ip route get دقیقاً همان رابط مورد انتظار را برمی‌گرداند، پس علاوه بر مسیرها استثناهای پروکسی را هم بررسی کنید.

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

مسیریابی سیاستی مهمان را بخوانید، نه فقط جدول اصلی

روی مهمان لینوکس سه فرمان فقط‌خواندنی لایه‌ها را جدا می‌کنند: ip -4 rule show برای قواعد سیاست، سپس ip -4 route get 168.63.129.16 و ip -4 route get 169.254.169.254 برای تصمیم‌هایی که هسته واقعاً می‌گیرد. آن‌ها را پیش و پس از اتصال VPN اجرا کنید. تفاوت این دو خروجی مجموعه تغییر شماست و از هر حدسی درباره کاری که کلاینت کرد سودمندتر است.

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

مقاومت کنید در برابر دستوری که هر دو مسیر /32 را از دروازه قدیمی اضافه می‌کند. مسیر پلتفرم link-local و گام بعدی عمومی WAN دو شیء متفاوتند و استثنای کلی تعارض واقعی سیاست را پنهان می‌کند.

مدیریت و بازیابی را جدا نگه دارید

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

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

استثنای تأییدشده را به نام مالک شبکه مهمان و پیکربندی VPN بنویسید، شامل اینکه هنگام اتصال دوباره و راه‌اندازی مجدد چه رخ می‌دهد. UDRهای Azure جدول مسیر مهمان نیستند و ویرایش آن‌ها قاعده سیاست محلی را درست نمی‌کند.