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 หรือ :: หมายถึงทุกที่อยู่ ขณะที่ที่อยู่เฉพาะหมายถึงเพียงที่เดียวนั้น หากเซิร์ฟเวอร์เคยเปลี่ยนที่อยู่ ผู้รับฟังที่ยังตรึงอยู่กับที่อยู่ที่ปลดระวางแล้วคือความล้มเหลวที่การตรวจนี้จับได้พอดี

ค่าที่กำหนดอยู่ในหน้า Management Service ของ IIS Manager บนโหนดเซิร์ฟเวอร์ และเบื้องหลังใน administration.config ในไดเรกทอรีการกำหนดค่า inetsrv เปรียบเทียบทั้งสอง: สิ่งที่ไฟล์บอก กับสิ่งที่ซ็อกเก็ตผูกอยู่จริง

จากนั้นเรียก Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed จากไคลเอนต์ VPN ที่ได้รับผลกระทบ และอ่านที่อยู่ที่แปลงแล้วกับที่อยู่ต้นทางที่เลือก เก็บชื่อโฮสต์และพอร์ตที่แน่นอนนั้นไว้ในตั๋ว เพราะการเปรียบเทียบภายหลังกับชื่ออื่นไม่ได้พิสูจน์อะไรเกี่ยวกับการเปลี่ยนแปลงที่คุณทำ

อ่านที่อยู่ต้นทางที่เซิร์ฟเวอร์เห็น

ข้อจำกัด IPv4 ของ WMSVC ถูกประเมินกับที่อยู่ที่มาถึงเซิร์ฟเวอร์ ซึ่งไม่ใช่ที่อยู่ที่แล็ปท็อปของคุณคิดว่าตัวเองมีเสมอไป หากพูล VPN ถูกแปลที่ใดที่หนึ่งตามเส้นทาง เซิร์ฟเวอร์จะเห็นที่อยู่ที่แปลแล้ว และรายการอนุญาตที่สร้างจากที่อยู่ภายในของไคลเอนต์จะปฏิเสธ การปฏิเสธนั้นดูเหมือนการเชื่อมต่อล้มเหลวจากฝั่งไคลเอนต์ จึงมักถูกวินิจฉัยผิดว่าเป็นปัญหาเส้นทาง

ใช้ผลลัพธ์โดยละเอียดของการทดสอบ TCP พร้อมตารางการเชื่อมต่อของเซิร์ฟเวอร์เอง เพื่อดูว่าที่อยู่ต้นทางใดมาถึงจริงก่อนแก้ไขรายการข้อจำกัด

เปลี่ยน ไบน์ดิง เป็นการเปลี่ยนแปลงบริการ

WMSVC ต้องถูกหยุดก่อนแก้ไขการกำหนดค่า ดังนั้นวางแผนเป็นการเปลี่ยนแปลงที่มีเส้นทางการบริหารอื่นใช้ได้ เช่น การเข้าถึงคอนโซลหรือเซสชันระยะไกลที่ไม่ขึ้นกับ IIS Manager หยุดบริการ นำการเปลี่ยนแปลงที่อยู่ พอร์ต หรือใบรับรองไปใช้ แล้วเริ่มใหม่และยืนยันว่าผู้รับฟังย้ายแล้ว คนอื่นที่ใช้การบริหาร IIS ระยะไกลจะสูญเสียเซสชันในช่วงนั้น แจ้งผู้ดูแลระบบคนอื่นก่อนหน้าต่างจะเปิด การค้นพบกลางการเปลี่ยนแปลงคือวิธีที่คนสองคนลงเอยด้วยการแก้ไขผู้รับฟังเดียวกัน

การเลือกทุกที่อยู่เป็นตัวเลือกที่ชอบด้วยกฎหมาย แต่ให้ถือเป็นการตัดสินใจเรื่องการเข้าถึง ไม่ใช่ทางลัด การขยายผู้รับฟังขณะรายการข้อจำกัดยังเปิดอยู่คือวิธีที่ปลายทางการบริหารกลายเป็นเปิดเผยบนเครือข่ายที่ไม่มีใครตั้งใจ หากเซิร์ฟเวอร์มีการ์ด NIC หลายใบ จำกัดผู้รับฟังไว้ที่อินเทอร์เฟซการบริหาร ปล่อยเส้นทางข้อมูลไว้ และยืนยันว่าไซต์ยังตอบบนที่อยู่ของตัวเอง

ใบรับรองที่ WMSVC นำเสนอถูกเลือกแยกจากใบรับรองของไซต์ หากเปลี่ยนที่อยู่ ให้ยืนยันว่าใบรับรองยังตรงกับชื่อโฮสต์ที่ไคลเอนต์ใช้ มิฉะนั้นการเชื่อมต่อจะล้มเหลวในขั้น TLS ด้วยข้อร้องเรียนที่ไม่เกี่ยวกับเส้นทางเลย

แยกความสามารถในการเข้าถึงออกจากความไว้วางใจและสิทธิ์

เมื่อ TCP สำเร็จ ความล้มเหลวที่เหลือเรียงตามลำดับ: ความไว้วางใจ TLS สำหรับใบรับรองการบริหาร จากนั้นการพิสูจน์ตัวตน Windows จากนั้นสิทธิ์ IIS Manager ที่ให้กับบัญชีนั้น แต่ละอย่างให้ข้อผิดพลาดต่างกัน และไม่มีอย่างใดแก้ได้ด้วยเส้นทางหรือกฎไฟร์วอลล์ อ่านข้อความข้อผิดพลาดตามตัวอักษรแทนการเริ่มบริการใหม่

ทำการตรวจสี่ข้อตามลำดับนั้น ปลายทาง ผู้รับฟัง ที่อยู่ต้นทาง ความไว้วางใจ และโดยปกติคุณจะพบ ไบน์ดิง ที่ล้าสมัยก่อนพบปัญหาเครือข่าย