IIS Manager uzaqdan idarəetmə: əvvəlcə WMSVC-nin öz ünvanını yoxlayın

Saytınız tunel vasitəsilə 443-də cavab verir, IIS Manager isə hələ də serverə qoşula bilmir. Bu iki nəticə ziddiyyət deyil, çünki veb sayt və uzaqdan idarəetmə son nöqtəsi iki fərqli konfiqurasiyaya və iki fərqli giriş qaydası dəstinə malik iki dinləyicidir. İdarəetmə dinləyicisi Veb İdarəetmə Xidmətinə, yəni WMSVC-yə aiddir və onun öz ünvanı, portu, sertifikatı və IPv4 məhdudiyyətləri var. Hər hansı marşruta toxunmadan əvvəl həmin son nöqtəni yoxlayın.

İki dinləyici, iki fərqli problem

Sayta gedən sorğu həmin sayt üçün HTTP.sys bağlantısına çatır və bu bağlantı applicationHost konfiqurasiyasında hər sayt və hər protokol üzrə müəyyən edilir. IIS Manager-dən gələn sorğu isə WMSVC-yə çatır; o, standart olaraq TCP 8172 üzərində HTTPS cavabı verir və server səviyyəsində konfiqurasiya olunur. Sayt bağlantısında heç nə WMSVC-nin harada dinlədiyini dəyişmir, WMSVC-də heç nə saytın hansı ünvanda cavab verdiyini dəyişmir. Onlar bir maşını və bir sertifikat anbarını paylaşır, oxşarlıq da burada bitir.

Yəni uğurlu Test-NetConnection port 443 üzərində sayt dinləyicisinin əlçatan olduğunu deyir və idarəetmə barədə heç nə demir.

WMSVC-nin həqiqətən bağlandığı ünvanı tapın

Serverdən illər əvvəl nə üçün konfiqurasiya edildiyini deyil, indi nəyi dinlədiyini soruşun. Get-NetTCPConnection -LocalPort 8172 -State Listen yerli ünvanı çap edir və 0.0.0.0 və ya :: dəyəri bütün ünvanlar deməkdir, konkret ünvan isə yalnız onu göstərir. Ünvanlaması dəyişdirilmiş serverdə hələ də köhnə ünvana bərkidilmiş dinləyici məhz bu yoxlamanın tutduğu nasazlıqdır.

Konfiqurasiya edilmiş dəyər server qovşağında IIS Manager-in İdarəetmə Xidməti səhifəsində, onun arxasında isə administration.config faylında, inetsrv konfiqurasiya qovluğunda yerləşir. İkisini müqayisə edin: faylın dediyi və soketin həqiqətən bağlandığı ünvan.

Sonra təsirlənmiş VPN müştərisindən Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed işə salın və həll olunmuş ünvanı və seçilmiş mənbə ünvanını oxuyun. VPN-də fərqli DNS cavabı kifayət qədər adi haldır və erkən istisna etməyə dəyər. Məhz həmin host adını və portu biletdə saxlayın, çünki sonradan başqa adla müqayisə etdiyiniz dəyişiklik barədə heç nə sübut etmir.

Serverin gördüyü mənbə ünvanını oxuyun

WMSVC-nin IPv4 məhdudiyyətləri serverə çatan ünvana görə qiymətləndirilir, bu isə həmişə noutbukunuzun öz bildiyi ünvan deyil. Əgər VPN hovuzu yolun hansısa yerində çevrilirsə, server çevrilmiş ünvanı görür və müştərinin daxili ünvanından qurulmuş icazə siyahısı onu rədd edir. Bu rədd müştəri tərəfindən qoşulma nasazlığı kimi görünür və buna görə də səhvən marşrut problemi kimi diaqnoz qoyulur.

Məhdudiyyət siyahısını redaktə etməzdən əvvəl hansı mənbə ünvanının həqiqətən gəldiyini görmək üçün TCP testinin ətraflı çıxışından və serverin öz qoşulma cədvəlindən istifadə edin.

Bağlantını xidmət dəyişikliyi kimi dəyişin

WMSVC-nin konfiqurasiyası redaktə olunmazdan əvvəl xidmət dayandırılmalıdır, ona görə də bunu başqa bir idarəetmə yolu mövcud olan dəyişiklik kimi planlaşdırın: konsol girişi və ya IIS Manager-dən asılı olmayan uzaq sessiya. Xidməti dayandırın, ünvan, port və ya sertifikat dəyişikliyini tətbiq edin, sonra işə salın və dinləyicinin yerini dəyişdiyini təsdiqləyin. Uzaq IIS idarəetməsindən istifadə edən hər kəs həmin pəncərə ərzində sessiyasını itirir. Pəncərə açılmazdan əvvəl digər administratorlara deyin; bunu dəyişikliyin ortasında kəşf etmək iki nəfərin eyni dinləyicini redaktə etməsi ilə bitir.

Bütün ünvanları seçmək qanuni bir seçimdir, lakin ona qısa yol kimi deyil, giriş qərarı kimi yanaşın. Məhdudiyyət siyahısı açıq qalarkən dinləyicini genişləndirmək idarəetmə son nöqtəsinin heç kimin nəzərdə tutmadığı şəbəkədə açıq qalmasına səbəb olur. Serverin bir neçə şəbəkə kartı varsa, dinləyicini idarəetmə interfeysi ilə məhdudlaşdırın, məlumat yoluna toxunmayın və saytın öz ünvanında cavab verdiyini təsdiqləyin.

WMSVC-nin təqdim etdiyi sertifikat sayt sertifikatlarından ayrı seçilir. Ünvanı dəyişsəniz, sertifikatın müştərilərin istifadə etdiyi host adına hələ də uyğun olduğunu təsdiqləyin, əks halda qoşulma sonradan TLS mərhələsində marşrutla heç bir əlaqəsi olmayan şikayətlə uğursuz olacaq.

Əlçatanlığı etibardan və icazələrdən ayırın

TCP uğurlu olduqdan sonra qalan nasazlıqlar sıralıdır: idarəetmə sertifikatı üçün TLS etimadı, sonra Windows autentifikasiyası, sonra həmin hesaba verilən IIS Manager icazələri. Onların hər biri fərqli xəta yaradır və heç biri marşrut və ya firewall qaydası ilə düzəlmir. Xidməti yenidən başlatmaq əvəzinə xəta mətnini hərfi oxuyun.

Dörd yoxlamanı bu ardıcıllıqla aparın: son nöqtə, dinləyici, mənbə ünvanı, etibar; və adətən şəbəkə problemini tapmadan əvvəl köhnəlmiş bağlantını tapacaqsınız.