IIS Manager დისტანციური მართვა: ჯერ WMSVC-ის საკუთარი მისამართი შეამოწმე

თქვენი საიტი 443-ზე პასუხობს გვირაბის გავლით, თუმცა IIS Manager მაინც ვერ უკავშირდება სერვერს. შედეგების ეს წყვილი წინააღმდეგობა არ არის, რადგან ვებსაიტი და დისტანციური ადმინისტრირების საბოლოო წერტილი ორი მსმენელია, ორი კონფიგურაციითა და წვდომის წესების ორი ნაკრებით. მართვის მსმენელი Web Management Service-ს, WMSVC-ს ეკუთვნის და მას თავისი მისამართი, პორტი, სერტიფიკატი და IPv4 შეზღუდვები აქვს. სანამ ერთ მარშრუტსაც კი შეეხებით, სწორედ ეს საბოლოო წერტილი შეამოწმეთ.

ორი მსმენელი, ორი განსხვავებული პრობლემა

საიტის მოთხოვნა აღწევს ამ საიტის HTTP.sys-ის მიბმამდე, რომელიც განსაზღვრულია საიტისა და პროტოკოლის მიხედვით applicationHost კონფიგურაციაში. IIS Manager-იდან მოთხოვნა აღწევს WMSVC-მდე, რომელიც ნაგულისხმევად HTTPS-ს პასუხობს TCP 8172-ზე და კონფიგურირებულია სერვერის დონეზე. საიტის მიბმაში არაფერი ცვლის იმას, სად უსმენს WMSVC, და WMSVC-ში არაფერი ცვლის იმას, რომელ მისამართზე პასუხობს საიტი. ისინი იზიარებენ მანქანასა და სერტიფიკატების საცავს და სწორედ იქ მთავრდება მსგავსება.

ასე რომ, წარმატებული Test-NetConnection 443 პორტზე გეუბნებათ, რომ საიტის მსმენელი მისაწვდომია და არაფერს ამბობს მართვაზე.

იპოვეთ მისამართი, რომელზეც WMSVC რეალურად არის მიბმული

ჰკითხეთ სერვერს, რას უსმენს ახლა და არა რაზე იყო კონფიგურირებული წლების წინ. Get-NetTCPConnection -LocalPort 8172 -State Listen ბეჭდავს ლოკალურ მისამართს, და მნიშვნელობა 0.0.0.0 ან :: ნიშნავს ყველა მისამართს, ხოლო კონკრეტული მისამართი ნიშნავს მხოლოდ მას. თუ სერვერის მისამართები შეიცვალა, გაუქმებულ მისამართზე მიმაგრებული მსმენელი სწორედ ის ხარვეზია, რომელსაც ეს შემოწმება იჭერს.

კონფიგურირებული მნიშვნელობა სერვერის კვანძზე IIS Manager-ის Management Service გვერდზეა, ხოლო მის უკან inetsrv კონფიგურაციის დირექტორიაში administration.config-ში. შეადარეთ ორივე: რას ამბობს ფაილი და რაზეა სოკეტი რეალურად მიბმული.

შემდეგ გაუშვით Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed დაზარალებული VPN კლიენტიდან და წაიკითხეთ ამოხსნილი მისამართი და არჩეული წყაროს მისამართი. VPN-ზე განსხვავებული DNS პასუხი საკმარისად ხშირია, რომ ადრევე გამოირიცხოს. ბილეთში შეინახეთ ზუსტად ის ჰოსტის სახელი და პორტი, რადგან მოგვიანებით სხვა სახელთან შედარება ვერაფერს ამტკიცებს თქვენს ცვლილებაზე.

წაიკითხეთ წყაროს მისამართი, რომელსაც სერვერი ხედავს

WMSVC-ის IPv4 შეზღუდვები ფასდება სერვერზე მისული მისამართის მიხედვით, რაც ყოველთვის არ არის ის მისამართი, რომელიც თქვენს ლეპტოპს, მისი აზრით, აქვს. თუ VPN-ის პულის ტრანსლაცია გზის რომელიმე წერტილში ხდება, სერვერი ხედავს ტრანსლირებულ მისამართს და კლიენტის შიდა მისამართზე აგებული დაშვების სია მას უარყოფს. ეს უარი კლიენტის მხრიდან კავშირის შეცდომად გამოიყურება, ამიტომაც ხშირად მარშრუტიზაციის პრობლემად არასწორად დიაგნოსტირდება.

გამოიყენეთ TCP ტესტის დეტალური გამოტანა და სერვერის საკუთარი კავშირების ცხრილი, რომ ნახოთ, რომელი წყაროს მისამართი მივიდა რეალურად, სანამ შეზღუდვების სიას შეცვლით.

შეცვალეთ მიბმა როგორც სერვისის ცვლილება

WMSVC უნდა გაჩერდეს მისი კონფიგურაციის რედაქტირებამდე, ამიტომ დაგეგმეთ ეს როგორც ცვლილება სხვა ხელმისაწვდომი მართვის გზით, მაგალითად კონსოლის წვდომით ან დისტანციური სესიით, რომელიც IIS Manager-ზე არ არის დამოკიდებული. შეაჩერეთ სერვისი, გამოიყენეთ მისამართის, პორტის ან სერტიფიკატის ცვლილება, შემდეგ გაუშვით ისევ და დაადასტურეთ, რომ მსმენელი გადავიდა. ყველა სხვა, ვინც დისტანციურ IIS ადმინისტრირებას იყენებს, ამ ფანჯრის განმავლობაში სესიას კარგავს. აცნობეთ სხვა ადმინისტრატორებს ფანჯრის გახსნამდე; ცვლილების შუაში ამის აღმოჩენა სწორედ ის გზაა, რომლითაც ორი ადამიანი ერთსა და იმავე მსმენელს არედაქტირებს.

ყველა მისამართის არჩევა ლეგიტიმური ვარიანტია, მაგრამ მას მოეპყარით როგორც წვდომის გადაწყვეტილებას და არა მოკლე გზას. მსმენელის გაფართოება იმ დროს, როცა შეზღუდვების სია ღია რჩება, სწორედ ის გზაა, რომლითაც მართვის საბოლოო წერტილი აღმოჩნდება გამოფენილი ქსელში, რომელიც არავის განუზრახავს. თუ სერვერს რამდენიმე NIC აქვს, შეზღუდეთ მსმენელი მართვის ინტერფეისით, მონაცემთა გზა ხელუხლებლად დატოვეთ და დაადასტურეთ, რომ საიტი კვლავ პასუხობს საკუთარ მისამართზე.

სერტიფიკატი, რომელსაც WMSVC წარადგენს, საიტის სერტიფიკატებისგან დამოუკიდებლად ირჩევა. თუ მისამართს შეცვლით, დაადასტურეთ, რომ სერტიფიკატი კვლავ ემთხვევა კლიენტების მიერ გამოყენებულ ჰოსტის სახელს, წინააღმდეგ შემთხვევაში კავშირი მოგვიანებით TLS საფეხურზე ჩავარდება საჩივრით, რომელსაც მარშრუტიზაციასთან არაფერი აქვს საერთო.

გამოყავით მისაწვდომობა ნდობისა და ნებართვებისგან

როცა TCP წარმატებით მუშაობს, დარჩენილი ხარვეზები რიგითია: TLS ნდობა მართვის სერტიფიკატისთვის, შემდეგ Windows-ის ავთენტიფიკაცია, შემდეგ ამ ანგარიშისთვის მინიჭებული IIS Manager-ის ნებართვები. თითოეული მათგანი სხვადასხვა შეცდომას იძლევა და არცერთი მათგანი არ სწორდება მარშრუტით ან firewall-ის წესით. წაიკითხეთ შეცდომის ტექსტი პირდაპირ, ნაცვლად სერვისის კიდევ ერთხელ გადატვირთვისა.

შეასრულეთ ოთხი შემოწმება ამ რიგით: საბოლოო წერტილი, მსმენელი, წყაროს მისამართი, ნდობა, და ჩვეულებრივ ძველ მიბმას იპოვით ქსელურ პრობლემამდე.