Saytingiz tunnel orqali 443 da javob beradi, IIS Manager esa baribir serverga ulanmayapti. Bu ikki natija qarama-qarshilik emas, chunki veb-sayt va masofaviy boshqaruv endpointi ikki xil konfiguratsiya va ikki xil kirish qoidalari to'plamiga ega ikki tinglovchi. Boshqaruv qismi Web Management Service, WMSVC ga tegishli va o'z manzili, porti, sertifikati hamda IPv4 cheklovlariga ega. Bitta yo'lga tegishdan oldin o'sha endpointni tekshiring.

Ikki tinglovchi, ikki xil muammo

Saytga so'rov o'sha saytning HTTP.sys bog'lanishiga yetib boradi, u applicationHost konfiguratsiyasida sayt va protokol bo'yicha aniqlanadi. IIS Manager dan so'rov WMSVC ga yetib boradi, u sukut bo'yicha TCP 8172 da HTTPS ga javob beradi va server darajasida sozlanadi. Sayt bog'lanishida hech narsa WMSVC qayerda tinglashini o'zgartirmaydi, WMSVC da hech narsa sayt qaysi manzilda javob berishini o'zgartirmaydi. Ular bitta mashina va bitta sertifikat omborini bo'lishadi, o'xshashlik shu yerda tugaydi.

Shuning uchun 443 portiga muvaffaqiyatli Test-NetConnection sayt tinglovchisiga yetish mumkinligini aytadi, boshqaruv haqida hech narsa aytmaydi.

WMSVC haqiqatda qaysi manzilga bog'langanini toping

Serverdan yillar oldin sozlangan narsani emas, hozir nimani tinglayotganini so'rang. Get-NetTCPConnection -LocalPort 8172 -State Listen mahalliy manzilni chiqaradi, 0.0.0.0 yoki :: qiymati barcha manzillarni, aniq manzil esa faqat o'shani bildiradi. Agar server manzillari o'zgargan bo'lsa, bekor qilingan manzilga hali ham bog'langan tinglovchi aynan shu tekshiruv ushlaydigan nosozlik.

Sozlangan qiymat server tugunidagi IIS Manager ning Management Service sahifasida, uning orqasida esa inetsrv konfiguratsiya katalogidagi administration.config ichida. Ikkalasini solishtiring: fayl nima deydi va soket haqiqatda nimaga bog'langan.

So'ngra zararlangan VPN mijozidan Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed ni ishga tushiring va hal qilingan manzil hamda tanlangan manba manzilini o'qing. VPN da boshqacha DNS javobi keng tarqalgan, shuning uchun uni erta istisno qilish arziydi. Tiketda aynan o'sha xost nomi va portni saqlang, chunki keyin boshqa nom bilan solishtirish siz qilgan o'zgarishni hech narsa isbotlamaydi.

Server ko'radigan manba manzilini o'qing

WMSVC ning IPv4 cheklovlari serverga yetib kelgan manzilga nisbatan baholanadi, u har doim noutbukingiz o'zida bor deb hisoblaydigan manzil emas. Agar VPN puli yo'lda biror joyda tarjima qilinsa, server tarjima qilingan manzilni ko'radi va mijozning ichki manzilidan tuzilgan ruxsat ro'yxati uni rad etadi. Bu rad etish mijoz tomonidan ulanish nosozligidek ko'rinadi, shuning uchun u ko'pincha yo'naltirish muammosi deb noto'g'ri tashxis qilinadi.

Cheklovlar ro'yxatini tahrirlashdan oldin qaysi manba manzil haqiqatda kelganini ko'rish uchun TCP testining batafsil chiqishidan va serverning o'z ulanish jadvalidan foydalaning.

Bog'lanishni xizmat o'zgarishi sifatida o'zgartiring

WMSVC konfiguratsiyasi tahrirlanishidan oldin to'xtatilishi kerak, shuning uchun uni konsolga kirish yoki IIS Manager ga bog'liq bo'lmagan masofaviy sessiya kabi boshqa boshqaruv yo'li mavjud o'zgarish sifatida rejalashtiring. Xizmatni to'xtating, manzil, port yoki sertifikat o'zgarishini qo'llang, so'ng uni qayta ishga tushiring va tinglovchi ko'chganini tasdiqlang. O'sha vaqt oralig'ida masofaviy IIS boshqaruvidan foydalanadigan har bir kishi sessiyasini yo'qotadi. Oyna ochilishidan oldin boshqa administratorlarga ayting; o'zgarish o'rtasida buni aniqlash ikki kishi bir xil tinglovchini tahrirlashni boshlashining yo'lidir.

Barcha manzillarni tanlash qonuniy variant, lekin unga qisqa yo'l emas, kirish qarori sifatida qarang. Cheklovlar ro'yxati ochiq turganda tinglovchini kengaytirish boshqaruv endpointining hech kim o'ylamagan tarmoqda ochiq qolishining yo'lidir. Agar serverda bir nechta NIC bo'lsa, tinglovchini boshqaruv interfeysi bilan cheklang, ma'lumot yo'liga tegmang va sayt hali ham o'z manzilida javob berishini tasdiqlang.

WMSVC taqdim etadigan sertifikat sayt sertifikatlaridan alohida tanlanadi. Manzilni o'zgartirsangiz, sertifikat mijozlar ishlatadigan xost nomiga hali ham mos kelishini tasdiqlang, aks holda ulanish keyinroq TLS bosqichida yo'naltirishga aloqasi yo'q shikoyat bilan muvaffaqiyatsiz bo'ladi.

Yetib borishni ishonch va ruxsatlardan ajrating

TCP muvaffaqiyatli o'tgach, qolgan nosozliklar tartiblangan: boshqaruv sertifikati uchun TLS ishonchi, keyin Windows autentifikatsiyasi, keyin o'sha hisobga berilgan IIS Manager ruxsatlari. Ularning har biri boshqa xato beradi va hech biri yo'l yoki firewall qoidasi bilan tuzatilmaydi. Xizmatni qayta ishga tushirish o'rniga xato matnini so'zma-so'z o'qing.

To'rtta tekshiruvni shu tartibda bajaring: endpoint, tinglovchi, manba manzil, ishonch, va odatda tarmoq muammosidan oldin eskirgan bog'lanishni topasiz.

O'xshash maqolalar