Administration distante avec IIS Manager : vérifiez d'abord l'adresse propre au WMSVC

Votre site répond sur 443 à travers le tunnel, et IIS Manager ne parvient toujours pas à joindre le serveur. Ces deux résultats ne se contredisent pas, car le site web et le point de terminaison d'administration distante sont deux écouteurs avec deux configurations et deux jeux de règles d'accès. Celui de l'administration appartient au service Web Management Service, WMSVC, et possède sa propre adresse, son port, son certificat et ses restrictions IPv4. Vérifiez ce point de terminaison avant de toucher à une seule route.

Deux écouteurs, deux problèmes différents

Une requête vers le site atteint la liaison HTTP.sys de ce site, définie par site et par protocole dans la configuration applicationHost. Une requête depuis IIS Manager atteint le WMSVC, qui répond par défaut en HTTPS sur TCP 8172 et se configure au niveau du serveur. Rien dans la liaison du site ne change l'endroit où le WMSVC écoute, et rien dans le WMSVC ne change l'adresse sur laquelle le site répond. Ils partagent une machine et un magasin de certificats, et c'est là que la ressemblance s'arrête.

Ainsi, un Test-NetConnection réussi sur le port 443 vous dit que l'écouteur du site est joignable, et absolument rien sur l'administration.

Trouvez l'adresse à laquelle le WMSVC est réellement lié

Demandez au serveur ce qu'il écoute maintenant, et non ce pour quoi il était configuré il y a des années. Get-NetTCPConnection -LocalPort 8172 -State Listen affiche l'adresse locale, et une valeur de 0.0.0.0 ou :: signifie toutes les adresses, tandis qu'une adresse précise ne signifie que celle-là. Si l'adressage d'un serveur a changé, un écouteur encore épinglé à une adresse retirée est exactement la panne que cette vérification attrape.

La valeur configurée se trouve sur la page Management Service d'IIS Manager au nœud du serveur, et derrière elle dans administration.config sous le répertoire de configuration inetsrv. Comparez les deux : ce que dit le fichier et ce à quoi la socket est réellement liée.

Exécutez ensuite Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed depuis le client VPN concerné et lisez l'adresse résolue et l'adresse source sélectionnée. Une réponse DNS différente sur le VPN est assez courante pour valoir la peine d'être écartée tôt. Conservez exactement ce nom d'hôte et ce port dans le ticket, car une comparaison ultérieure avec un autre nom ne prouve rien sur la modification que vous avez faite.

Lisez l'adresse source que le serveur voit

Les restrictions IPv4 du WMSVC sont évaluées par rapport à l'adresse qui arrive au serveur, et ce n'est pas toujours l'adresse que votre portable croit avoir. Si le pool VPN est traduit quelque part sur le chemin, le serveur voit l'adresse traduite et une liste d'autorisation construite à partir de l'adresse interne du client la refusera. Ce refus ressemble côté client à un échec de connexion, et c'est pourquoi il est diagnostiqué à tort comme un problème de routage.

Utilisez la sortie détaillée du test TCP et la table de connexions du serveur lui-même pour voir quelle adresse source est réellement arrivée avant de modifier la liste de restrictions.

Changez la liaison comme un changement de service

Le WMSVC doit être arrêté avant que sa configuration soit modifiée, alors planifiez-le comme un changement avec un autre chemin d'administration disponible, par exemple un accès console ou une session distante qui ne dépend pas d'IIS Manager. Arrêtez le service, appliquez le changement d'adresse, de port ou de certificat, puis démarrez-le et confirmez que l'écouteur a bougé. Toute autre personne utilisant l'administration IIS distante perd sa session pendant cette fenêtre. Prévenez les autres administrateurs avant l'ouverture de la fenêtre ; le découvrir en pleine modification est la façon dont deux personnes finissent par modifier le même écouteur.

Choisir toutes les adresses est une option légitime, mais traitez-la comme une décision d'accès et non comme un raccourci. Élargir l'écouteur alors que la liste de restrictions reste ouverte est la façon dont un point de terminaison d'administration finit exposé sur un réseau que personne n'avait prévu. Si le serveur a plusieurs cartes réseau, limitez l'écouteur à l'interface d'administration, laissez le chemin de données tranquille et confirmez que le site répond toujours sur sa propre adresse.

Le certificat présenté par le WMSVC est choisi séparément des certificats du site. Si vous changez l'adresse, confirmez que le certificat correspond toujours au nom d'hôte utilisé par les clients, sinon la connexion échouera plus tard à l'étape TLS avec une plainte qui n'a rien à voir avec le routage.

Séparez l'accessibilité de la confiance et des autorisations

Une fois TCP réussi, les pannes restantes sont ordonnées : confiance TLS du certificat d'administration, puis authentification Windows, puis les autorisations IIS Manager accordées à ce compte. Chacune produit une erreur différente, et aucune n'est corrigée par une route ou une règle de pare-feu. Lisez le texte de l'erreur littéralement au lieu de redémarrer le service une fois de plus.

Faites les quatre vérifications dans cet ordre, point de terminaison, écouteur, adresse source, confiance, et vous trouverez généralement la liaison obsolète avant de trouver un problème de réseau.