IIS Manager zdalnie: najpierw sprawdź własny adres WMSVC

Twoja witryna odpowiada na 443 przez tunel, a IIS Manager nadal nie może połączyć się z serwerem. Ta para wyników nie jest sprzecznością, ponieważ witryna i punkt końcowy zdalnej administracji to dwa odbiorniki z dwiema konfiguracjami i dwoma zestawami reguł dostępu. Ten administracyjny należy do Web Management Service, WMSVC, i ma własny adres, port, certyfikat oraz ograniczenia IPv4. Sprawdź ten punkt końcowy, zanim dotkniesz choćby jednej trasy.

Dwa odbiorniki, dwa różne problemy

Żądanie do witryny trafia do powiązania HTTP.sys tej witryny, definiowanego osobno dla witryny i protokołu w konfiguracji applicationHost. Żądanie z IIS Manager trafia do WMSVC, który domyślnie odpowiada HTTPS na TCP 8172 i jest konfigurowany na poziomie serwera. Nic w powiązaniu witryny nie zmienia miejsca nasłuchu WMSVC i nic w WMSVC nie zmienia adresu, na którym odpowiada witryna. Dzielą maszynę i magazyn certyfikatów i tam kończy się podobieństwo.

Udany Test-NetConnection na port 443 mówi więc, że odbiornik witryny jest osiągalny, i nic nie mówi o administracji.

Znajdź adres, do którego WMSVC jest faktycznie przypisany

Zapytaj serwer, czego teraz nasłuchuje, a nie co skonfigurowano lata temu. Get-NetTCPConnection -LocalPort 8172 -State Listen wypisuje adres lokalny, a wartość 0.0.0.0 lub :: oznacza wszystkie adresy, podczas gdy konkretny adres oznacza tylko ten jeden. Jeśli adresacja serwera została zmieniona, odbiornik wciąż przypięty do wycofanego adresu to dokładnie ta awaria, którą wychwytuje to sprawdzenie.

Skonfigurowana wartość znajduje się na stronie Management Service w IIS Manager w węźle serwera, a za nią w administration.config w katalogu konfiguracji inetsrv. Porównaj oba: co mówi plik i do czego gniazdo jest faktycznie przypisane.

Następnie uruchom Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed z dotkniętego klienta VPN i odczytaj rozwiązywany adres oraz wybrany adres źródłowy. Inna odpowiedź DNS przez VPN jest wystarczająco częsta, by wykluczyć ją wcześnie. Zachowaj w zgłoszeniu dokładnie tę nazwę hosta i port, ponieważ późniejsze porównanie z inną nazwą niczego nie dowodzi w sprawie wprowadzonej zmiany.

Odczytaj adres źródłowy, który widzi serwer

Ograniczenia IPv4 WMSVC są oceniane względem adresu, który dociera do serwera, a nie zawsze jest to adres, który Twój laptop uważa za swój. Jeśli pula VPN jest gdzieś na trasie tłumaczona, serwer widzi adres przetłumaczony, a lista dozwolonych zbudowana z wewnętrznego adresu klienta go odrzuci. Ta odmowa wygląda po stronie klienta jak błąd połączenia, dlatego często jest błędnie diagnozowana jako problem routingu.

Użyj szczegółowych danych wyjściowych testu TCP oraz własnej tabeli połączeń serwera, aby zobaczyć, który adres źródłowy faktycznie dotarł, zanim edytujesz listę ograniczeń.

Zmień powiązanie jako zmianę usługi

WMSVC trzeba zatrzymać przed edycją konfiguracji, więc zaplanuj to jako zmianę z inną dostępną ścieżką administracji, na przykład dostępem do konsoli lub sesją zdalną niezależną od IIS Manager. Zatrzymaj usługę, zastosuj zmianę adresu, portu lub certyfikatu, następnie uruchom ją i potwierdź, że odbiornik się przeniósł. Każdy inny użytkownik zdalnej administracji IIS traci w tym oknie sesję. Poinformuj innych administratorów przed otwarciem okna; odkrycie tego w środku zmiany to sposób, w jaki dwie osoby zaczynają edytować ten sam odbiornik.

Wybór wszystkich adresów jest legalną opcją, ale traktuj go jako decyzję o dostępie, a nie skrót. Rozszerzanie odbiornika przy otwartej liście ograniczeń to sposób, w jaki punkt końcowy administracji zostaje wystawiony w sieci, której nikt nie zamierzał. Jeśli serwer ma kilka kart NIC, ogranicz odbiornik do interfejsu administracyjnego, zostaw ścieżkę danych w spokoju i potwierdź, że witryna nadal odpowiada na własnym adresie.

Certyfikat przedstawiany przez WMSVC jest wybierany oddzielnie od certyfikatów witryny. Jeśli zmieniasz adres, potwierdź, że certyfikat nadal pasuje do nazwy hosta używanej przez klientów, w przeciwnym razie połączenie później nie powiedzie się na etapie TLS ze skargą niemającą nic wspólnego z routingiem.

Oddziel osiągalność od zaufania i uprawnień

Gdy TCP się powiedzie, pozostałe awarie są uporządkowane: zaufanie TLS do certyfikatu administracyjnego, potem uwierzytelnianie Windows, potem uprawnienia IIS Manager przyznane temu kontu. Każda z nich daje inny błąd i żadnej nie naprawia trasa ani reguła zapory. Czytaj tekst błędu dosłownie, zamiast ponownie uruchamiać usługę.

Przejdź cztery sprawdzenia w tej kolejności: punkt końcowy, odbiornik, adres źródłowy, zaufanie, a zwykle znajdziesz nieaktualne powiązanie, zanim znajdziesz problem sieciowy.