IIS Manager remoto: verifique primeiro o endereço do próprio WMSVC

O seu site responde na 443 através do túnel, e o IIS Manager continua sem conseguir ligar-se ao servidor. Este par de resultados não é uma contradição, porque o site e o endpoint de administração remota são dois listeners com duas configurações e dois conjuntos de regras de acesso. O da gestão pertence ao Web Management Service, WMSVC, e tem o seu próprio endereço, porta, certificado e restrições IPv4. Verifique esse endpoint antes de tocar numa única rota.

Dois listeners, dois problemas diferentes

Um pedido ao site chega à ligação HTTP.sys desse site, definida por site e por protocolo na configuração applicationHost. Um pedido do IIS Manager chega ao WMSVC, que por predefinição responde HTTPS no TCP 8172 e é configurado ao nível do servidor. Nada na ligação do site altera onde o WMSVC escuta, e nada no WMSVC altera o endereço a que o site responde. Partilham uma máquina e um arquivo de certificados, e é aí que a semelhança acaba.

Portanto, um Test-NetConnection com êxito na porta 443 diz que o listener do site está acessível, e nada sobre a gestão.

Encontre o endereço a que o WMSVC está realmente ligado

Pergunte ao servidor em que está a escutar agora, e não o que foi configurado há anos. Get-NetTCPConnection -LocalPort 8172 -State Listen imprime o endereço local, e um valor 0.0.0.0 ou :: significa todos os endereços, enquanto um endereço específico significa apenas esse. Se o endereçamento de um servidor foi alterado, um listener ainda preso a um endereço retirado é exatamente a falha que esta verificação apanha.

O valor configurado está na página Management Service do IIS Manager no nó do servidor, e por detrás dela em administration.config no diretório de configuração inetsrv. Compare os dois: o que diz o ficheiro, e a que está o socket realmente ligado.

Depois execute Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed a partir do cliente VPN afetado e leia o endereço resolvido e o endereço de origem selecionado. Uma resposta DNS diferente na VPN é suficientemente comum para valer a pena excluir cedo. Guarde esse nome de anfitrião e porta exatos no ticket, porque uma comparação posterior com outro nome não prova nada sobre a alteração que fez.

Leia o endereço de origem que o servidor vê

As restrições IPv4 do WMSVC são avaliadas em relação ao endereço que chega ao servidor, que nem sempre é o endereço que o seu portátil pensa ter. Se a pool VPN for traduzida em algum ponto do caminho, o servidor vê o endereço traduzido e uma lista de permissões construída a partir do endereço interno do cliente irá recusá-lo. Essa recusa parece, do lado do cliente, uma falha de ligação, e é por isso que é frequentemente mal diagnosticada como um problema de encaminhamento.

Use a saída detalhada do teste TCP, juntamente com a tabela de ligações do próprio servidor, para ver que endereço de origem chegou realmente antes de editar a lista de restrições.

Altere a ligação como uma alteração de serviço

O WMSVC tem de ser parado antes de a configuração ser editada, por isso planeie-o como uma alteração com outro caminho de gestão disponível, como acesso à consola ou uma sessão remota que não dependa do IIS Manager. Pare o serviço, aplique a alteração de endereço, porta ou certificado, depois inicie-o e confirme que o listener mudou. Qualquer outra pessoa a usar a administração remota do IIS perde a sessão nesse intervalo. Avise os outros administradores antes de a janela abrir; descobri-lo a meio da alteração é como duas pessoas acabam a editar o mesmo listener.

Escolher todos os endereços é uma opção legítima, mas trate-a como uma decisão de acesso e não como um atalho. Alargar o listener enquanto a lista de restrições fica aberta é como um endpoint de gestão acaba exposto numa rede que ninguém pretendia. Se o servidor tiver várias NIC, restrinja o listener à interface de gestão, deixe o caminho de dados em paz e confirme que o site continua a responder no seu próprio endereço.

O certificado que o WMSVC apresenta é selecionado separadamente dos certificados do site. Se alterar o endereço, confirme que o certificado ainda corresponde ao nome de anfitrião que os clientes usam, ou a ligação falhará mais tarde no passo TLS com uma queixa que nada tem a ver com encaminhamento.

Separe a acessibilidade da confiança e das permissões

Assim que o TCP funcionar, as falhas restantes estão ordenadas: confiança TLS para o certificado de gestão, depois autenticação Windows, depois as permissões do IIS Manager concedidas a essa conta. Cada uma produz um erro diferente, e nenhuma delas é resolvida por uma rota ou uma regra de firewall. Leia o texto do erro à letra em vez de reiniciar o serviço outra vez.

Faça as quatro verificações nessa ordem, endpoint, listener, endereço de origem, confiança, e normalmente encontrará a ligação obsoleta antes de encontrar um problema de rede.