IIS Manager віддалено: спершу перевірте власну адресу WMSVC

Ваш сайт відповідає на 443 через тунель, а IIS Manager усе одно не може підключитися до сервера. Ця пара результатів не суперечність, бо сайт і кінцева точка віддаленого адміністрування — два прослуховувачі з двома конфігураціями й двома наборами правил доступу. Керуючий належить Web Management Service, 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 або :: означає всі адреси, а конкретна адреса — лише її. Якщо адресацію сервера змінено, прослуховувач, досі прикріплений до виведеної з ужитку адреси, — саме та несправність, яку ловить ця перевірка.

Налаштоване значення міститься на сторінці Management Service у 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, надані цьому обліковому запису. Кожен із них дає іншу помилку, і жоден не виправляється маршрутом або правилом брандмауера. Читайте текст помилки буквально, замість того щоб знову перезапускати службу.

Пройдіть чотири перевірки в цьому порядку: кінцева точка, прослуховувач, вихідна адреса, довіра, і ви зазвичай знайдете застаріле прив'язування раніше, ніж проблему мережі.