ข้อผิดพลาด 720 ของ VPN ใน Windows: พูลแอดเดรสหรือการผูกไคลเอ็นต์?
ข้อผิดพลาด 720 หมายความว่าการเชื่อมต่อไม่เคยได้รับแอดเดรสที่ใช้งานได้ แยกความล้มเหลวในโฮสต์เดียวออกจากความล้มเหลวในหลายโฮสต์ก่อนติดตั้งอะแดปเตอร์ใหม่
ข้อผิดพลาด 720 ปรากฏหลังรับข้อมูลรับรองแล้ว จึงทำให้ผู้คนกลับไปที่ช่องรหัสผ่าน การเชื่อมต่อไปถึงจุดที่เจรจาแอดเดรสและไม่ได้รับแอดเดรส ความล้มเหลวสองแบบที่ต่างกันมากสร้างกล่องโต้ตอบเดียวกัน: เซิร์ฟเวอร์ไม่มีอะไรจะแจก หรือไคลเอ็นต์รายนี้ไม่สามารถเจรจาให้เสร็จได้ การแยกสองอย่างนี้ออกก่อนแตะต้องสิ่งใดคือส่วนใหญ่ของการซ่อม และการแยกนี้มีบันทึกไว้ในหน้าตรวจสอบปัญหาเรื่องข้อผิดพลาด 720 ของ Microsoft
สิ่งที่กล่องโต้ตอบไม่ได้บอก
ข้อความอธิบายความล้มเหลวในการเจรจา PPP และจงใจคลุมเครือเพราะไคลเอ็นต์มองไม่เห็นว่าเซิร์ฟเวอร์ปฏิเสธเพราะอะไร ไม่ใช่ข้อผิดพลาดของข้อมูลรับรอง และไม่ใช่คำกล่าวเกี่ยวกับการเข้ารหัสของอุโมงค์ หมายความว่าแอดเดรสหรือพารามิเตอร์การเจรจาไม่ได้ถูกส่งไป
ฝั่งเซิร์ฟเวอร์สาเหตุปกติคือการจัดสรร: พูลแบบคงที่ของ RRAS ที่ไม่มีแอดเดรสว่าง หรือการกำหนดค่า DHCP ที่ขอบเขตหมดหรือเข้าถึงไม่ได้ ให้อาการเดียวกันนี้กับทุกไคลเอ็นต์ที่ลอง ฝั่งไคลเอ็นต์สาเหตุปกติคือการผูก WAN Miniport ที่พา PPP ต้องผูกกับคอมโพเนนต์ที่ถูกต้อง และการผูกที่ปิดใช้งานหรือฟิลเตอร์เครือข่ายที่แทรกเข้ามาสามารถหยุดการเจรจาได้โดยไม่มีปัญหาเครื่องที่มองเห็น สองตระกูลนี้ต้องการหลักฐานต่างกัน และวิธีเร็วที่สุดในการเลือกระหว่างสองอย่างคือการนับว่ามีกี่ไคลเอ็นต์ที่ได้รับผลกระทบ
แยกประชากรก่อน แล้วค่อยดูพูล
นับไคลเอ็นต์ที่ได้รับผลกระทบก่อนอ่านการกำหนดค่าใด ๆ ความล้มเหลวที่กระทบทุกคนพร้อมกันคือสภาวะของเซิร์ฟเวอร์ และความล้มเหลวที่ตามเครื่องเดียวข้ามเครือข่ายคือสภาวะของไคลเอ็นต์ การนับนั้นใช้ข้อความเดียวในช่องแชตและประหยัดเวลาบ่ายโมงหนึ่ง
| Artifact | How you get it | What it rules out | What it cannot rule out |
|---|---|---|---|
| Affected-client count | One message to the people who failed, or a search of today's tickets | A client-only fault, when every client failed within minutes | Which server-side component stopped allocating |
| RRAS event for one attempt | Get-WinEvent on the System log, filtered to the allocation event id | An allocation failure, when no event matches that attempt | A binding fault that appears later in the same negotiation |
| Hidden WAN Miniport bindings | Get-NetAdapter with hidden adapters, then the binding list on the returned name | A disabled ms_wanarp binding or an inserted filter on this client | Pool exhaustion that would also have hit other clients |
| Free-address count | The RRAS pool view, or the DHCP scope statistics | A committed static range or an exhausted scope | Why the address was not delivered to one specific client |
จากนั้นเชื่อมโยงความพยายามที่ล้มเหลวหนึ่งครั้งกับบันทึกของเซิร์ฟเวอร์เอง เพราะ RRAS บันทึกเหตุการณ์เมื่อจัดสรรไม่ได้ และเหตุการณ์นั้นระบุชื่อความล้มเหลวไม่ใช่อาการ ถ้าความล้มเหลวตามไคลเอ็นต์ใดไคลเอ็นต์หนึ่ง บันทึกของเซิร์ฟเวอร์จะไม่แสดงอะไรสำหรับความพยายามนั้น ซึ่งเป็นข้อมูลในตัวเอง การไม่มีข้อผิดพลาดการจัดสรรทำให้ปัญหาจำกัดอยู่ที่การเจรจาบนไคลเอ็นต์นั้นและบอกว่าต้องรันคำสั่งใดต่อไป
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }อ่านสถานะการจัดสรรของเซิร์ฟเวอร์
ฝั่ง RRAS ยืนยันว่าวิธีจัดสรรใดถูกกำหนดค่าไว้จริง ไม่ใช่วิธีที่เอกสารสันนิษฐาน พูลแบบคงที่และการกำหนดค่าที่ส่งผ่าน DHCP ล้มเหลวต่างกัน และการแก้ไขเป็นของการตั้งค่าที่ใช้อยู่ สำหรับพูลแบบคงที่ ให้นับแอดเดรสว่างและมองหาการกำหนดต่อผู้ใช้ที่ถือสัญญาเช่าที่ไม่มีใครจำได้ว่าให้ไว้ เพราะพูลที่ดูใหญ่สามารถถูกจองเต็มได้ สำหรับ DHCP ให้ตรวจสอบว่ารีเลย์ไปถึงเซิร์ฟเวอร์และขอบเขตมีสัญญาเช่าว่าง
ขอบเขตที่ถูกใช้หมดโดยไคลเอ็นต์ทั่วไปให้ข้อผิดพลาด 720 เดียวกับพูลที่กำหนดค่าผิด และคอนโซล RRAS จะดูสมบูรณ์ดีทั้งสองกรณี ต่อต้านวิธีแก้ที่สืบทอดมาคือการแบ่งพูลเป็นขอบเขตเล็กลง: คำแนะนำเดิมบรรยายผลลัพธ์ของผู้ดูแลระบบคนหนึ่ง และไม่ได้ซ่อมความล้มเหลวการจัดสรรที่เหตุการณ์ของเซิร์ฟเวอร์เองระบุได้โดยตรง
อ่านการผูกของไคลเอ็นต์โดยไม่ทำให้พัง
หากหลักฐานชี้ไปที่ไคลเอ็นต์เดียว ให้ตรวจสอบอะแดปเตอร์ที่ซ่อนอยู่แทนการติดตั้งสแต็กใหม่ คำสั่งแรกแสดงอินเทอร์เฟซ WAN Miniport และชื่อของอินเทอร์เฟซเหล่านั้น คำสั่งที่สองใช้ชื่อที่มันคืนมา ไม่ใช่ชื่อที่คัดลอกจากคู่มือ
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsอ่านรายการเพื่อหาการผูกการแก้ไขแอดเดรสและฟิลเตอร์ของบุคคลที่สาม การผูกที่ปิดใช้งานคือการซ่อมแบบเจาะจง ขณะที่การมีอยู่ของฟิลเตอร์เป็นคำถามถึงเจ้าของซอฟต์แวร์นั้น ไม่ใช่การอนุญาตให้ปิดผลิตภัณฑ์ความปลอดภัย การลบอะแดปเตอร์ทั้งหมดคือการกระทำเดียวที่ทำลายหลักฐานที่คุณจะต้องใช้หากความล้มเหลวกลับมา
หลังการแก้ไข ให้ลองโปรไฟล์เดิมอีกครั้งแล้วทำกรณีสองไคลเอ็นต์ซ้ำหากนั่นคืออาการเริ่มต้น เพราะการเชื่อมต่อแรกที่สำเร็จซ่อนปัญหาการจัดสรรที่ไคลเอ็นต์ที่สองเผยออกมา เก็บบันทึกเป็นสี่ฟิลด์: ไคลเอ็นต์ใด การผูกใด เหตุการณ์ใด และอะไรเปลี่ยนไป เปลี่ยนทีละชั้นต่อการลองเพราะการแก้ไขฝั่งไคลเอ็นต์และการเปลี่ยนพูลพร้อมกันไม่สามารถระบุสาเหตุได้ และความล้มเหลวถัดไปจะดูใหม่แม้จะเป็นอันเดียวกัน