IIS Manager på distans: kontrollera WMSVC:s egen adress först

Din webbplats svarar på 443 genom tunneln, och IIS Manager kan fortfarande inte ansluta till servern. Det paret av resultat är ingen motsägelse, eftersom webbplatsen och slutpunkten för fjärradministration är två lyssnare med två konfigurationer och två uppsättningar åtkomstregler. Den för administration tillhör Web Management Service, WMSVC, och har egen adress, port, certifikat och IPv4-begränsningar. Kontrollera den slutpunkten innan du rör en enda route.

Två lyssnare, två olika problem

En begäran till webbplatsen når HTTP.sys-bindningen för den webbplatsen, som definieras per webbplats och per protokoll i applicationHost-konfigurationen. En begäran från IIS Manager når WMSVC, som som standard svarar HTTPS på TCP 8172 och konfigureras på servernivå. Ingenting i webbplatsens bindning ändrar var WMSVC lyssnar, och ingenting i WMSVC ändrar vilken adress webbplatsen svarar på. De delar maskin och certifikatarkiv, och där slutar likheten.

Så en lyckad Test-NetConnection mot port 443 säger att webbplatsens lyssnare är nåbar, och ingenting om administration.

Hitta adressen som WMSVC faktiskt är bunden till

Fråga servern vad den lyssnar på nu, inte vad som konfigurerades för år sedan. Get-NetTCPConnection -LocalPort 8172 -State Listen skriver ut den lokala adressen, och ett värde på 0.0.0.0 eller :: betyder alla adresser, medan en specifik adress bara betyder den. Om en servers adressering har ändrats är en lyssnare som fortfarande sitter fast på en avvecklad adress precis det fel som den här kontrollen fångar.

Det konfigurerade värdet finns på sidan Management Service i IIS Manager på servernoden, och bakom den i administration.config i konfigurationskatalogen inetsrv. Jämför de två: vad filen säger och vad socketen faktiskt är bunden till.

Kör sedan Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed från den drabbade VPN-klienten och läs den upplösta adressen och den valda källadressen. Ett annat DNS-svar över VPN är vanligt nog att utesluta tidigt. Spara exakt det värdnamnet och den porten i ärendet, eftersom en senare jämförelse med ett annat namn inte bevisar något om ändringen du gjorde.

Läs källadressen som servern ser

WMSVC:s IPv4-begränsningar utvärderas mot adressen som kommer fram till servern, som inte alltid är adressen som din laptop tror att den har. Om VPN-poolen översätts någonstans längs vägen ser servern den översatta adressen, och en tillåtelselista byggd från klientens inre adress kommer att avvisa den. Den avvisningen ser från klientsidan ut som ett anslutningsfel, och därför diagnostiseras den ofta felaktigt som ett routingproblem.

Använd den detaljerade utskriften från TCP-testet, tillsammans med serverns egen anslutningstabell, för att se vilken källadress som faktiskt kom fram innan du redigerar begränsningslistan.

Ändra bindningen som en tjänsteändring

WMSVC måste stoppas innan konfigurationen redigeras, så planera det som en ändring med en annan tillgänglig administrationsväg, till exempel konsolåtkomst eller en fjärrsession som inte är beroende av IIS Manager. Stoppa tjänsten, tillämpa ändringen av adress, port eller certifikat, starta den sedan och bekräfta att lyssnaren flyttades. Alla andra som använder fjärradministration av IIS förlorar sin session under det fönstret. Säg till de andra administratörerna innan fönstret öppnas; att upptäcka det mitt i ändringen är hur två personer börjar redigera samma lyssnare.

Att välja alla adresser är ett legitimt alternativ, men behandla det som ett åtkomstbeslut och inte som en genväg. Att vidga lyssnaren medan begränsningslistan står öppen är hur en administrationsslutpunkt blir exponerad på ett nätverk som ingen avsåg. Om servern har flera nätverkskort, begränsa lyssnaren till administrationsgränssnittet, låt datavägen vara och bekräfta att webbplatsen fortfarande svarar på sin egen adress.

Certifikatet som WMSVC presenterar väljs separat från webbplatsens certifikat. Om du ändrar adressen, bekräfta att certifikatet fortfarande matchar värdnamnet som klienterna använder, annars misslyckas anslutningen senare i TLS-steget med ett klagomål som inte har något med routing att göra.

Skilj nåbarhet från förtroende och behörigheter

När TCP lyckas är de återstående felen ordnade: TLS-förtroende för administrationscertifikatet, sedan Windows-autentisering, sedan IIS Manager-behörigheterna som ges till det kontot. Var och en ger ett annat fel, och inget av dem åtgärdas av en route eller en brandväggsregel. Läs feltexten bokstavligt i stället för att starta om tjänsten.

Gå igenom de fyra kontrollerna i den ordningen, slutpunkt, lyssnare, källadress, förtroende, och du hittar vanligtvis den föråldrade bindningen innan du hittar ett nätverksproblem.