IIS Manager uzaktan: önce WMSVC'nin kendi adresini denetleyin

Siteniz tünel üzerinden 443'te yanıt veriyor ama IIS Manager hâlâ sunucuya bağlanamıyor. Bu iki sonuç çelişki değildir, çünkü web sitesi ile uzaktan yönetim uç noktası iki ayrı yapılandırmaya ve iki ayrı erişim kuralı kümesine sahip iki dinleyicidir. Yönetim tarafındaki Web Management Service, WMSVC'ye aittir ve kendi adresi, portu, sertifikası ve IPv4 kısıtları vardır. Tek bir yola dokunmadan önce o uç noktayı denetleyin.

İki dinleyici, iki farklı sorun

Siteye giden istek o sitenin HTTP.sys bağlamasına ulaşır; bu bağlama applicationHost yapılandırmasında site ve protokol bazında tanımlanır. IIS Manager'den gelen istek WMSVC'ye ulaşır; WMSVC varsayılan olarak TCP 8172 üzerinde HTTPS yanıtı verir ve sunucu düzeyinde yapılandırılır. Sitenin bağlamasında hiçbir şey WMSVC'nin dinlediği yeri değiştirmez ve WMSVC'de hiçbir şey sitenin yanıt verdiği adresi değiştirmez. Bir makineyi ve bir sertifika deposunu paylaşırlar, benzerlik orada biter.

Yani 443 portuna karşı başarılı bir Test-NetConnection, sitenin dinleyicisine ulaşılabildiğini söyler, yönetim hakkında hiçbir şey söylemez.

WMSVC'nin gerçekte hangi adrese bağlı olduğunu bulun

Sunucuya yıllar önce ne yapılandırıldığını değil, şu anda neyi dinlediğini sorun. Get-NetTCPConnection -LocalPort 8172 -State Listen yerel adresi yazdırır; 0.0.0.0 veya :: değeri tüm adresler anlamına gelirken belirli bir adres yalnızca onu belirtir. Bir sunucunun adreslemesi değiştiyse, kullanımdan kaldırılmış bir adrese hâlâ sabitlenmiş bir dinleyici tam da bu denetimin yakaladığı arızadır.

Yapılandırılmış değer sunucu düğümündeki IIS Manager'ın Management Service sayfasında, arkasında ise inetsrv yapılandırma dizinindeki administration.config içinde bulunur. İkisini karşılaştırın: dosyanın söylediği şey ve soketin gerçekte neye bağlı olduğu.

Ardından etkilenen VPN istemcisinden Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed çalıştırın ve çözümlenen adresi ve seçilen kaynak adresi okuyun. VPN üzerinde farklı bir DNS yanıtı oldukça yaygındır, bu yüzden erken elemeye değer. Bilette tam olarak o ana bilgisayar adını ve portu saklayın, çünkü daha sonra başka bir adla yapılan karşılaştırma yaptığınız değişiklik hakkında hiçbir şey kanıtlamaz.

Sunucunun gördüğü kaynak adresi okuyun

WMSVC'nin IPv4 kısıtları sunucuya ulaşan adrese göre değerlendirilir, ki bu her zaman dizüstü bilgisayarınızın sahip olduğunu sandığı adres değildir. VPN havuzu yolun bir yerinde çevriliyorsa sunucu çevrilmiş adresi görür ve istemcinin iç adresinden oluşturulan izin listesi onu reddeder. Bu ret, istemci tarafından bir bağlantı hatası gibi görünür, bu yüzden sıklıkla yönlendirme sorunu olarak yanlış teşhis edilir.

Kısıtlama listesini düzenlemeden önce hangi kaynak adresin gerçekten geldiğini görmek için TCP testinin ayrıntılı çıktısını ve sunucunun kendi bağlantı tablosunu kullanın.

Bağlamayı bir hizmet değişikliği olarak değiştirin

WMSVC'nin yapılandırması düzenlenmeden önce durdurulması gerekir, bu yüzden bunu konsol erişimi veya IIS Manager'a bağlı olmayan uzak bir oturum gibi başka bir yönetim yolu bulunan bir değişiklik olarak planlayın. Hizmeti durdurun, adres, port veya sertifika değişikliğini uygulayın, sonra yeniden başlatın ve dinleyicinin taşındığını doğrulayın. O pencerede uzaktan IIS yönetimini kullanan herkes oturumunu kaybeder. Pencere açılmadan önce diğer yöneticilere haber verin; değişikliğin ortasında bunu keşfetmek iki kişinin aynı dinleyiciyi düzenlemeye başlamasının yoludur.

Tüm adresleri seçmek meşru bir seçenektir, ancak bunu kısayol değil erişim kararı olarak ele alın. Kısıtlama listesi açıkken dinleyiciyi genişletmek, bir yönetim uç noktasının kimsenin amaçlamadığı bir ağda açığa çıkmasının yoludur. Sunucuda birkaç NIC varsa dinleyiciyi yönetim arayüzüyle sınırlayın, veri yolunu rahat bırakın ve sitenin hâlâ kendi adresinde yanıt verdiğini doğrulayın.

WMSVC'nin sunduğu sertifika, site sertifikalarından ayrı olarak seçilir. Adresi değiştirirseniz sertifikanın istemcilerin kullandığı ana bilgisayar adıyla hâlâ eşleştiğini doğrulayın, aksi halde bağlantı daha sonra TLS adımında yönlendirmeyle hiç ilgisi olmayan bir şikayetle başarısız olur.

Erişilebilirliği güvenden ve izinlerden ayırın

TCP başarılı olduğunda kalan arızalar sıralıdır: yönetim sertifikası için TLS güveni, ardından Windows kimlik doğrulaması, ardından o hesaba verilen IIS Manager izinleri. Her biri farklı bir hata üretir ve hiçbiri bir yol veya güvenlik duvarı kuralıyla düzeltilmez. Hizmeti yeniden başlatmak yerine hata metnini harfiyen okuyun.

Dört denetimi bu sırayla yapın, uç nokta, dinleyici, kaynak adres, güven, ve genellikle bir ağ sorunu bulmadan önce eski bağlamayı bulursunuz.