Uw site antwoordt op 443 via de tunnel, en IIS Manager kan nog steeds geen verbinding maken met de server. Die twee resultaten zijn geen tegenspraak, want de website en het eindpunt voor beheer op afstand zijn twee listeners met twee configuraties en twee sets toegangsregels. Die van beheer hoort bij de Web Management Service, WMSVC, en heeft een eigen adres, poort, certificaat en IPv4-beperkingen. Controleer dat eindpunt voordat u ook maar één route aanraakt.

Twee listeners, twee verschillende problemen

Een verzoek aan de site bereikt de HTTP.sys-binding van die site, die per site en per protocol in de applicationHost-configuratie is gedefinieerd. Een verzoek van IIS Manager bereikt WMSVC, dat standaard HTTPS op TCP 8172 beantwoordt en op serverniveau wordt geconfigureerd. Niets aan de binding van de site verandert waar WMSVC luistert, en niets aan WMSVC verandert op welk adres de site antwoordt. Ze delen een machine en een certificaatarchief, en daar houdt de overeenkomst op.

Een geslaagde Test-NetConnection naar poort 443 zegt dus dat de listener van de site bereikbaar is, en niets over beheer.

Vind het adres waaraan WMSVC werkelijk is gebonden

Vraag de server waarop hij nu luistert, niet wat jaren geleden is geconfigureerd. Get-NetTCPConnection -LocalPort 8172 -State Listen drukt het lokale adres af, en een waarde van 0.0.0.0 of :: betekent alle adressen, terwijl een specifiek adres alleen dat ene betekent. Als de adressering van een server is gewijzigd, is een listener die nog aan een buiten gebruik gesteld adres vastzit precies de fout die deze controle vangt.

De geconfigureerde waarde staat op de pagina Management Service van IIS Manager op het serverknooppunt, en daarachter in administration.config in de configuratiemap inetsrv. Vergelijk de twee: wat het bestand zegt, en waaraan de socket werkelijk is gebonden.

Voer daarna Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed uit vanaf de getroffen VPN-client en lees het opgeloste adres en het gekozen bronadres. Een ander DNS-antwoord over de VPN komt vaak genoeg voor om vroeg uit te sluiten. Bewaar die exacte hostnaam en poort in het ticket, want een latere vergelijking met een andere naam bewijst niets over de wijziging die u hebt aangebracht.

Lees het bronadres dat de server ziet

De IPv4-beperkingen van WMSVC worden beoordeeld op het adres dat bij de server aankomt, dat niet altijd het adres is dat uw laptop denkt te hebben. Als de VPN-pool ergens onderweg wordt vertaald, ziet de server het vertaalde adres en een toegangslijst die is opgebouwd uit het interne adres van de client zal het weigeren. Die weigering ziet er aan de clientkant uit als een verbindingsfout, en daarom wordt ze vaak verkeerd gediagnosticeerd als een routeringsprobleem.

Gebruik de gedetailleerde uitvoer van de TCP-test, plus de eigen verbindingstabel van de server, om te zien welk bronadres werkelijk is aangekomen voordat u de beperkingslijst bewerkt.

Wijzig de binding als een servicewijziging

WMSVC moet worden gestopt voordat de configuratie wordt bewerkt, dus plan dit als een wijziging met een ander beheerpad beschikbaar, zoals consoletoegang of een externe sessie die niet van IIS Manager afhangt. Stop de service, pas de wijziging van adres, poort of certificaat toe, start hem dan en bevestig dat de listener is verplaatst. Iedereen die op dat moment IIS op afstand beheert, verliest zijn sessie. Waarschuw de andere beheerders voordat het venster opengaat; het midden in de wijziging ontdekken is hoe twee mensen dezelfde listener gaan bewerken.

Alle adressen kiezen is een legitieme optie, maar behandel het als een toegangsbeslissing en niet als een snelkoppeling. De listener verbreden terwijl de beperkingslijst open blijft, is hoe een beheereindpunt bloot komt te staan op een netwerk dat niemand bedoelde. Als de server meerdere NIC's heeft, beperk de listener dan tot de beheerinterface, laat het datapad met rust en bevestig dat de site nog steeds op zijn eigen adres antwoordt.

Het certificaat dat WMSVC presenteert, wordt apart van de sitecertificaten gekozen. Als u het adres wijzigt, bevestig dan dat het certificaat nog steeds past bij de hostnaam die clients gebruiken, anders mislukt de verbinding later bij de TLS-stap met een klacht die niets met routering te maken heeft.

Scheid bereikbaarheid van vertrouwen en machtigingen

Zodra TCP slaagt, zijn de resterende fouten geordend: TLS-vertrouwen voor het beheercertificaat, dan Windows-verificatie, dan de IIS Manager-machtigingen die aan dat account zijn verleend. Elk daarvan geeft een andere fout, en geen ervan wordt opgelost door een route of een firewallregel. Lees de fouttekst letterlijk in plaats van de service opnieuw te starten.

Doorloop de vier controles in die volgorde, eindpunt, listener, bronadres, vertrouwen, en u vindt meestal de verouderde binding voordat u een netwerkprobleem vindt.

Gerelateerde artikelen