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, выданные этой учётной записи. Каждый из них даёт другую ошибку, и ни один не исправляется маршрутом или правилом брандмауэра. Читайте текст ошибки буквально, вместо того чтобы снова перезапускать службу.

Пройдите четыре проверки в этом порядке: конечная точка, прослушиватель, исходный адрес, доверие, и вы обычно найдёте устаревшую привязку раньше, чем проблему сети.