جهاز Azure VM لا يصل إلى IMDS أو WireServer بعد تشغيل VPN

الجهاز يعمل، وعميل VPN يقول إنه متصل، ثم يبدأ وكيل Azure بالإبلاغ عن حالة غير سليمة بعد دقائق. أحياناً تصمد جلسة SSH بينما لا يعمل Run Command من البوابة، وهذا يدفع الناس إلى فحص الوكيل بدل جدول المسارات. قرارات إعادة التوجيه داخل الضيف تغيّرت عند صعود النفق، وعنوانان من عناوين المنصة هما عادة أول الضحايا. أتعامل مع ذلك كعَرَض توجيه قبل أن أتعامل معه كخلل في الوكيل.

العَرَض يبدو كأن الوكيل معطوب

يُقترح العنوانان أدناه كحل، وهما ليسا الخدمة نفسها. نسخ /32 لأحدهما لأنه نفع مع الآخر هو بالضبط كيف يتحول حل مؤقت إلى إعداد دائم لا يجرؤ أحد على إزالته.

الترتيب الذي ينجح هو تأكيد العنوان الذي يستهدفه الاستدعاء الفاشل فعلاً، ثم قراءة كيف يحلّه الضيف. أي شيء آخر هو تخمين بخطوات إضافية ونافذة تغيير أطول.

168.63.129.16 ليس وجهة عامة

168.63.129.16 هو عنوان المنصة الافتراضية الخاص في Azure، ومن أدواره WireServer الذي يستخدمه وكيل الجهاز للتحدث إلى النسيج. توثّق Microsoft أن حركة الوكيل إلى منفذي TCP 80 و 32526 يجب أن تبقى متاحة. وهو ليس مضيف إنترنت عادياً، وليس شيئاً ينبغي لنفق VPN كامل أن يحمله إلى مخرج بعيد. لهذا يمكن لنفق يبدو سليماً أن يترك الوكيل بلا اتصال.

كما تقول وثائق عنوان المنصة إن هذا العنوان لا يخضع للمسارات المعرّفة من المستخدم، وهذه خاصية في نسيج Azure وليست وعداً بشأن ضيفك. لا تزال قاعدة جدار حماية محلية أو سياسة التوجيه الخاصة بعميل VPN قادرة على كسر المسار، ولا شيء من ذلك يعيش في جدول مسارات الشبكة الافتراضية.

إذا كان الوكيل هو من يبلّغ عن المشكلة، فافحص حالة الخدمة والمسار إلى ذلك العنوان قبل إعادة تثبيت أي شيء.

169.254.169.254 له قواعده الخاصة

169.254.169.254 هو العنوان المحلي للرابط الخاص بخدمة Azure Instance Metadata Service. للطلبات إليه متطلباتها: بطاقة الشبكة الأساسية والعنوان IP الأساسي، وإعداد DHCP يدعم العنوان، وتجاوز أي وكيل HTTP. إرسالها عبر مخرج VPN بعيد أو بوابة إنترنت عشوائية ليس نموذج الوصول الذي تصفه Microsoft.

شرط الوكيل هذا يمسك بمن أصلح المسار وما زال يرى إخفاقات. يمكن لوكيل HTTP داخل الضيف أن يكسر IMDS بينما يعيد ip route get الواجهة التي تتوقعها بالضبط، لذا افحص استثناءات الوكيل إلى جانب المسارات.

لا تلصق استجابات البيانات الوصفية في تذكرة دعم أثناء تشخيص هذا. فقد تحمل بيانات اعتماد وتفاصيل نسخة تعيش أطول من الحادثة.

اقرأ سياسة التوجيه في الضيف، وليس الجدول الرئيسي فقط

على ضيف Linux تفصل ثلاثة أوامر للقراءة فقط الطبقات: ip -4 rule show لقواعد السياسة، ثم ip -4 route get 168.63.129.16 و ip -4 route get 169.254.169.254 للقرارات التي تتخذها النواة فعلاً. شغّلها قبل اتصال VPN وبعده. الفرق بين هذين المخرجين هو مجموعة تغييراتك، وهو أنفع من أي تخمين حول ما فعله العميل.

عميل VPN يثبّت قواعد سياسة يمكنه ترك الجدول الرئيسي دون مساس مع إعادة توجيه تلك الاستعلامات. لهذا يبدو حل الجدول الرئيسي وحده ناجحاً على مضيف ولا يفعل شيئاً على التالي. تضيف الأجهزة ذات بطاقات الشبكة المتعددة المشكلة نفسها من الاتجاه الآخر، لأن الإجابة تعتمد على أي بطاقة وأي عنوان مصدر تختاره القاعدة.

قاوم الوصفة التي تضيف مساري /32 كليهما عبر البوابة القديمة. مسار منصة محلي للرابط والقفزة التالية العامة لشبكة WAN كائنان مختلفان، والاستثناء الشامل يخفي تعارض السياسة الحقيقي.

أبقِ الإدارة والاستعادة منفصلتين

يمكن أن يلتقط افتراضي النفق الكامل رد SSH أو RDP أيضاً، لكنه يستهدف العنوان المرصود للمسؤول لا أي طرف من أطراف المنصة. شخّصه من زوج طلبه ورده الخاص، واحتفظ بقناة استعادة مستقلة مثل وحدة التحكم التسلسلية قبل تغيير سياسة VPN. إذا أعاد نشر تشغيل الجهاز وأبلغ الوكيل عن حالة غير سليمة، فافحص الإجراء المسجل والخدمة المسؤولة بدل افتراض أن تغيير المسار سبب إعادة التشغيل.

ثم تحقق من التدفقات الثلاثة منفصلة: المورد الخاص الذي أردته فعلاً، وتواصل الوكيل والمنصة المدعوم، ومسار الإدارة. استعادة أحدها ليست دليلاً على أن الآخرين نجيا.

اكتب الاستثناء المعتمد باسم مالك شبكة الضيف وإعداد VPN، بما في ذلك ما يحدث عند إعادة الاتصال وإعادة التشغيل. مسارات UDR في Azure ليست جدول مسارات الضيف، وتحريرها لن يصلح قاعدة سياسة محلية.