IIS Manager 원격 관리: 먼저 WMSVC 자체 주소를 확인하세요

사이트는 터널을 통해 443에서 응답하는데도 IIS Manager는 여전히 서버에 연결하지 못합니다. 웹사이트와 원격 관리 엔드포인트가 각각 다른 구성과 다른 액세스 규칙을 가진 두 개의 수신기이므로 이 두 결과는 모순이 아닙니다. 관리 쪽은 Web Management Service, WMSVC에 속하며 자체 주소, 포트, 인증서, IPv4 제한을 가집니다. 단 하나의 경로도 건드리기 전에 그 엔드포인트를 확인하세요.

두 수신기, 두 가지 다른 문제

사이트로 가는 요청은 해당 사이트의 HTTP.sys 바인딩에 도달하며, 이는 applicationHost 구성에서 사이트별, 프로토콜별로 정의됩니다. IIS Manager의 요청은 WMSVC에 도달하며, WMSVC는 기본적으로 TCP 8172에서 HTTPS로 응답하고 서버 수준에서 구성됩니다. 사이트 바인딩은 WMSVC가 수신하는 위치를 바꾸지 않고, WMSVC는 사이트가 응답하는 주소를 바꾸지 않습니다. 둘은 머신과 인증서 저장소를 공유하며, 유사점은 거기서 끝납니다.

따라서 443 포트에 대한 Test-NetConnection 성공은 사이트 수신기에 도달할 수 있다는 것만 알려 주고, 관리에 대해서는 아무것도 알려 주지 않습니다.

WMSVC가 실제로 바인딩된 주소 찾기

몇 년 전 구성된 값이 아니라 지금 무엇을 수신하는지 서버에 물어보세요. Get-NetTCPConnection -LocalPort 8172 -State Listen는 로컬 주소를 출력하며, 값이 0.0.0.0 또는 ::이면 모든 주소, 특정 주소면 그 하나만 의미합니다. 서버 주소가 바뀌었는데 수신기가 폐기된 주소에 고정되어 있다면 바로 이 점검이 잡아내는 장애입니다.

구성 값은 서버 노드의 IIS Manager Management Service 페이지에 있고, 그 뒤로는 inetsrv 구성 디렉터리의 administration.config에 있습니다. 파일이 말하는 값과 소켓이 실제로 바인딩된 대상을 비교하세요.

그런 다음 영향을 받은 VPN 클라이언트에서 Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed를 실행해 확인된 주소와 선택된 원본 주소를 읽으세요. VPN에서 DNS 응답이 다른 것은 흔하므로 일찍 배제할 가치가 있습니다. 나중에 다른 이름과 비교하면 수행한 변경을 증명하지 못하므로 티켓에 정확한 호스트 이름과 포트를 남기세요.

서버가 보는 원본 주소 읽기

WMSVC의 IPv4 제한은 서버에 도착한 주소를 기준으로 평가되며, 그 주소는 노트북이 스스로 가지고 있다고 믿는 주소와 항상 같지는 않습니다. 경로 어딘가에서 VPN 풀이 변환되면 서버는 변환된 주소를 보게 되고, 클라이언트 내부 주소로 만든 허용 목록은 이를 거부합니다. 이 거부는 클라이언트 쪽에서 연결 실패처럼 보이므로 라우팅 문제로 오진되기 쉽습니다.

제한 목록을 편집하기 전에 어떤 원본 주소가 실제로 도착했는지 확인하려면 TCP 테스트의 상세 출력과 서버 자체 연결 표를 사용하세요.

바인딩을 서비스 변경으로 다루기

WMSVC는 구성을 편집하기 전에 중지해야 하므로 콘솔 접근이나 IIS Manager에 의존하지 않는 원격 세션 같은 다른 관리 경로를 준비한 변경으로 계획하세요. 서비스를 중지하고 주소, 포트, 인증서 변경을 적용한 뒤 다시 시작해 수신기가 이동했는지 확인하세요. 그 시간 동안 원격 IIS 관리를 쓰는 다른 사람은 세션을 잃습니다. 변경 도중에 발견하면 두 사람이 같은 수신기를 편집하게 되므로 창이 열리기 전에 다른 관리자에게 알리세요.

모든 주소를 선택하는 것은 정당한 옵션이지만 지름길이 아니라 액세스 결정으로 다루세요. 제한 목록이 열린 채로 수신기를 넓히는 것이 관리 엔드포인트가 아무도 의도하지 않은 네트워크에 노출되는 방식입니다. 서버에 NIC가 여러 개라면 수신기를 관리 인터페이스로 제한하고 데이터 경로는 그대로 두며 사이트가 자체 주소에서 계속 응답하는지 확인하세요.

WMSVC가 제시하는 인증서는 사이트 인증서와 별도로 선택됩니다. 주소를 바꾼 뒤 인증서가 클라이언트가 쓰는 호스트 이름과 일치하지 않으면 연결이 나중에 TLS 단계에서 라우팅과 무관한 불만과 함께 실패하므로 반드시 일치 여부를 확인하세요.

도달 가능성과 신뢰, 권한 분리

TCP가 성공하면 남은 실패는 관리 인증서의 TLS 신뢰, Windows 인증, 그 계정에 부여된 IIS Manager 권한 순서로 정해집니다. 각각 다른 오류를 내고 어느 것도 경로나 방화벽 규칙으로 해결되지 않습니다. 서비스를 다시 시작하는 대신 오류 문구를 그대로 읽으세요.

엔드포인트, 수신기, 원본 주소, 신뢰 순서로 네 가지 점검을 진행하면 보통 네트워크 문제를 찾기 전에 오래된 바인딩을 찾게 됩니다.