إدارة IIS Manager عن بعد: افحص عنوان WMSVC الخاص أولاً

موقعك يجيب على 443 عبر النفق، ومع ذلك لا يستطيع IIS Manager الاتصال بالخادم. هاتان النتيجتان ليستا تناقضاً، لأن الموقع ونقطة الإدارة عن بعد مستمعان لهما إعدادان ومجموعتان من قواعد الوصول. المستمع الإداري يخص خدمة إدارة الويب WMSVC، وله عنوانه ومنفذه وشهادته وقيود IPv4 الخاصة به. افحص تلك النقطة قبل أن تلمس أي مسار.

مستمعان، مشكلتان مختلفتان

يصل الطلب إلى الموقع إلى ارتباط HTTP.sys الخاص بذلك الموقع، وهو مُعرَّف لكل موقع ولكل بروتوكول في إعداد applicationHost. أما الطلب من IIS Manager فيصل إلى WMSVC، الذي يجيب افتراضياً عبر HTTPS على TCP 8172 ويُضبط على مستوى الخادم. لا شيء في ارتباط الموقع يغيّر مكان استماع WMSVC، ولا شيء في WMSVC يغيّر العنوان الذي يجيب عليه الموقع. يتشاركان جهازاً ومخزن شهادات، وهنا ينتهي التشابه.

إذن، نجاح Test-NetConnection على المنفذ 443 يخبرك أن مستمع الموقع يمكن الوصول إليه، ولا شيء على الإطلاق عن الإدارة.

اعثر على العنوان المرتبط به WMSVC فعلياً

اسأل الخادم عمّا يستمع إليه الآن، لا عمّا كان مُعدّاً للاستماع إليه قبل سنوات. Get-NetTCPConnection -LocalPort 8172 -State Listen يطبع العنوان المحلي، وقيمة 0.0.0.0 أو :: تعني كل العناوين، بينما عنوان محدد يعني ذلك العنوان فقط. إذا غُيّر عنوان خادم ما، فإن مستمعاً ما زال مثبتاً على عنوان مسحوب هو بالضبط الفشل الذي يكتشفه هذا الفحص.

القيمة المُعدّة موجودة في صفحة خدمة الإدارة في IIS Manager على عقدة الخادم، وخلفها في administration.config ضمن دليل إعداد inetsrv. قارن الاثنين: ما يقوله الملف، وما يرتبط به المقبس فعلياً.

ثم شغّل Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed من عميل VPN المتأثر واقرأ العنوان المُحلَّل وعنوان المصدر المختار. اختلاف إجابة DNS على VPN أمر شائع بما يكفي لاستبعاده مبكراً. احتفظ بذلك الاسم والمنفذ بالضبط في التذكرة، لأن مقارنة لاحقة باسم آخر لا تثبت شيئاً عن التغيير الذي أجريته.

اقرأ عنوان المصدر الذي يراه الخادم

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

استخدم المخرجات التفصيلية لاختبار TCP، إضافة إلى جدول اتصالات الخادم نفسه، لترى أي عنوان مصدر وصل فعلاً قبل أن تعدّل قائمة القيود.

غيّر الارتباط كتغيير خدمة

يجب إيقاف WMSVC قبل تحرير إعداده، لذا خطط لذلك كتغيير مع مسار إداري آخر متاح، مثل الوصول إلى الطرفية أو جلسة بعيدة لا تعتمد على IIS Manager. أوقف الخدمة، وطبّق تغيير العنوان أو المنفذ أو الشهادة، ثم شغّلها وأكّد أن المستمع انتقل. أي شخص آخر يستخدم إدارة IIS عن بعد سيفقد جلسته خلال تلك النافذة. أبلغ المديرين الآخرين قبل فتح النافذة؛ فاكتشاف ذلك في منتصف التغيير هو كيف ينتهي شخصان إلى تحرير المستمع نفسه.

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

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

افصل الوصول عن الثقة والأذونات

بعد نجاح TCP، ترتيب الأعطال المتبقية: ثقة TLS بشهادة الإدارة، ثم مصادقة Windows، ثم أذونات IIS Manager الممنوحة لذلك الحساب. كل واحد منها ينتج خطأ مختلفاً، ولا يُصلح أي منها بمسار أو قاعدة جدار حماية. اقرأ نص الخطأ حرفياً بدل إعادة تشغيل الخدمة مرة أخرى.

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