مدیریت از راه دور IIS Manager: ابتدا آدرس خود WMSVC را بررسی کنید

سایت شما از طریق تونل روی 443 پاسخ می‌دهد و IIS Manager هنوز نمی‌تواند به سرور متصل شود. این دو نتیجه متناقض نیستند، زیرا وب‌سایت و نقطه پایانی مدیریت از راه دور دو شنونده با دو پیکربندی و دو مجموعه قاعده دسترسی هستند. شنونده مدیریت به سرویس مدیریت وب، WMSVC، تعلق دارد و آدرس، درگاه، گواهی و محدودیت‌های IPv4 خودش را دارد. پیش از دست زدن به حتی یک مسیر، همان نقطه پایانی را بررسی کنید.

دو شنونده، دو مشکل متفاوت

درخواست به سایت به اتصال HTTP.sys همان سایت می‌رسد که برای هر سایت و هر پروتکل در پیکربندی applicationHost تعریف می‌شود. درخواست از IIS Manager به WMSVC می‌رسد که به‌طور پیش‌فرض روی TCP 8172 با HTTPS پاسخ می‌دهد و در سطح سرور پیکربندی می‌شود. هیچ چیز در اتصال سایت تغییر نمی‌دهد که 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 اعطاشده به آن حساب. هر یک خطای متفاوتی تولید می‌کند و هیچ‌کدام با مسیر یا قاعده فایروال درست نمی‌شود. متن خطا را تحت‌اللفظی بخوانید به‌جای اینکه سرویس را دوباره راه‌اندازی کنید.

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