รหัสข้อผิดพลาด VPN ของ Windows: ขั้นตอนใดล้มเหลว และควรบันทึกอะไร
829, 703, 720, 691, 649: แต่ละหมายเลขบอกชื่อขั้นตอน และแต่ละขั้นตอนมีหลักฐานของตัวเอง บันทึกความพยายามหนึ่งครั้ง เปรียบเทียบบันทึกของเกตเวย์ เปลี่ยนเพียงชั้นเดียว
เปิดกล่องโต้ตอบ VPN ของ Windows หลังจากเกิดความล้มเหลว แล้วคุณจะได้หมายเลขและประโยคหนึ่ง ซึ่งประโยคมักเป็นครึ่งที่ใช้งานได้น้อยกว่า หมายเลขบอกว่าขั้นตอนใดของการเชื่อมต่อล้มเหลว และขั้นตอนนั้นกำหนดว่าควรดูบันทึก การตั้งค่า และทีมใดต่อไป การไล่ตามขั้นตอนตามลำดับใช้เวลาราวสิบนาทีและป้องกันลำดับที่คุ้นเคย คือการติดตั้งอะแดปเตอร์ใหม่ การสลับโปรโตคอล และการรีเซ็ตสแตก เพื่อซ่อมบัญชีที่ไม่เคยได้รับอนุญาตให้หมุนสายเลย
อ่านหมายเลขเป็นขั้นตอน
การเชื่อมต่อแบบเนทีฟผ่านสี่หมุดหมาย มันไปถึงเซิร์ฟเวอร์และสร้างลิงก์ เจรจาความปลอดภัย ตรวจสอบผู้ใช้ และใช้การกำหนดที่อยู่และการกำหนดเส้นทาง ความล้มเหลวในแต่ละจุดทิ้งหลักฐานต่างกัน และรหัสที่เป็นของขั้นตอนหนึ่งไม่บอกอะไรที่เป็นประโยชน์เกี่ยวกับขั้นตอนอื่น
ข้อผิดพลาดที่ต้องหลีกเลี่ยงคือการถือว่ารหัสเป็นระดับความรุนแรง ความล้มเหลวของลิงก์และความล้มเหลวของการอนุญาตอ่านเป็น "เชื่อมต่อไม่ได้" ทั้งคู่ และไม่มีอะไรอื่นที่เหมือนกัน ความรุนแรงบอกว่าอะไรเร่งด่วนเพียงใด ส่วนขั้นตอนบอกว่าควรเปิดอะไร
| Code family | Stage | Where the evidence lives |
|---|---|---|
| 829, 703 | Link or dial completion | Client event log, remote listener reachability |
| 720 | PPP negotiation and miniport binding | Adapter state, bindings, client log detail |
| 691, 649, 812 | Identity and authorization | Gateway or authentication server decision |
| Connected, no traffic | Addressing, routing and resolution | Route table and resolver configuration |
ขั้นตอนที่หนึ่ง: ลิงก์และความพยายามหมุนสาย
829 หมายถึงลิงก์พื้นฐานขาดหาย มันไม่บอกว่าฝ่ายปลายทางหยุดตอบ กล่องกลางฆ่าเซสชัน หรือนโยบายบนไคลเอนต์ปิดมัน รหัสการหมุนสายสำเร็จอย่าง 703 ยิ่งเร็วกว่านั้น: ความพยายามไม่เคยไปถึงขั้นมีลิงก์ ซึ่งมักชี้ไปที่โปรไฟล์ สถานะบริการ หรือนโยบายท้องถิ่น
Get-VpnConnection -Name 'Corp' | Select-Object Name,ServerAddress,TunnelType,AuthenticationMethod,ConnectionStatus
Test-NetConnection -ComputerName vpn.example.net -Port 443
Get-WinEvent -LogName Application -MaxEvents 200 | Where-Object ProviderName -match 'RasClient' | Select-Object -First 15 TimeCreated,Id,Messageการสอบถามเหตุการณ์คือส่วนที่คนข้าม บันทึกฝั่งไคลเอนต์ที่มีตราเวลาและชื่ออินเทอร์เฟซมีค่ามากกว่ากล่องโต้ตอบ เพราะมันบอกว่าความพยายามออกจากเครื่องหรือไม่ การไม่มีบันทึกและการไม่มีการตอบจากผู้ฟังหมายถึงปัญหาการเข้าถึง และการแก้ไขไคลเอนต์ไม่ว่าจะมากเพียงใดก็ไม่เปลี่ยนสิ่งนั้น
ถ้าโปรไฟล์เดียวกันทำงานได้บนเครือข่ายอื่น ให้หยุดตรงนี้ รหัสกำลังอธิบายสภาพของเส้นทาง ไม่ใช่ข้อผิดพลาดของการกำหนดค่า และการเปรียบเทียบที่มีประโยชน์ถัดไปคือการดักจับสองครั้ง ไม่ใช่การติดตั้งใหม่ครั้งอื่น
ขั้นตอนที่สอง: PPP และการผูกมินิพอร์ต
720 อยู่ระหว่างลิงก์กับผู้ใช้ อุโมงค์ขึ้นมาแล้ว จากนั้นชั้น PPP ไม่สามารถเจรจาที่อยู่หรือโปรโตคอลควบคุมได้ ซึ่งมักเป็นปัญหาการผูกบนไคลเอนต์ ไม่ใช่ข้อมูลรับรองที่ถูกปฏิเสธ ความแตกต่างนั้นคือคุณค่าทั้งหมดของรหัส: มันบอกว่าไม่เคยไปถึงข้อมูลรับรอง บัญชีจึงไม่ใช่ผู้ต้องสงสัย
Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -match 'WAN Miniport' | Select-Object Name,Status,ifIndex
Get-NetAdapterBinding | Where-Object ComponentID -match 'ms_pptp|ms_l2tp|ms_sstp|ms_agile' | Select-Object Name,ComponentID,Enabledการอ่านผลลัพธ์สองอย่างนั้นให้ข้อมูลมากกว่าการรีเซ็ตสิ่งใด มินิพอร์ตที่มีอยู่แต่ไม่ได้เริ่ม หรือการผูกโปรโตคอลที่ซอฟต์แวร์อื่นปิดไว้ ทำให้เกิดความล้มเหลวของขั้นตอนนี้พอดี ทั้งสองแก้ได้โดยไม่ต้องแตะส่วนที่เหลือของสแตก การรีเซ็ตทั้งหมดตรงกันข้ามกลับลบการกำหนดที่อยู่และสถานะตัวกรองที่ไม่เกี่ยวอะไรกับความผิดพลาด
ขั้นตอนที่สาม: ตัวตนและการอนุญาต
691 หมายถึงข้อมูลรับรองถูกปฏิเสธ 649 หมายถึงบัญชีไม่ได้รับอนุญาตให้หมุนสาย และ 812 หมายถึงนโยบายการเข้าถึงระยะไกลปฏิเสธการเชื่อมต่อ สิ่งเหล่านี้คือการตัดสินใจ ไม่ใช่ความผิดพลาดของการขนส่ง และไคลเอนต์ทำได้เพียงรายงาน
หลักฐานอยู่อีกฝั่ง ขอให้ผู้ดูแลเกตเวย์แสดงความพยายามที่ตราเวลานั้นและนโยบายที่ตรงกัน ถามเจ้าของไดเรกทอรีว่าบัญชีมีสิทธิ์หมุนสายหรือไม่ และอยู่ในกลุ่มที่นโยบายกำหนดหรือไม่ การเปลี่ยนชนิดอุโมงค์หรือติดตั้งไคลเอนต์ใหม่ไม่สามารถเปลี่ยนการตัดสินใจเกี่ยวกับตัวตนได้
นิสัยที่มีประโยชน์ในขั้นตอนนี้คือเขียนสตริงบัญชีที่แน่นอนลงในตั๋ว รวมถึงคำนำหน้าโดเมนใด ๆ จำนวนเคส 691 ที่น่าประหลาดใจคือข้อมูลรับรองที่บันทึกไว้สำหรับโดเมนผิด และสิ่งนั้นเห็นได้ในสตริงบัญชี ไม่ใช่ในการตั้งค่าโปรโตคอล
ขั้นตอนที่สี่: เชื่อมต่อแล้ว แต่ไม่มีอะไรทำงาน
การเชื่อมต่ออาจเสร็จสมบูรณ์และยังไร้ประโยชน์ มันถือที่อยู่ ไคลเอนต์รายงานความสำเร็จ และทุกคำขอของแอปพลิเคชันหมดเวลา ไม่มีอะไรในกล่องโต้ตอบสะท้อนสิ่งนั้น และไม่มีรหัสให้ค้นหา ณ จุดนั้นกล่องโต้ตอบจบลง และหลักฐานที่มีประโยชน์อยู่ที่อื่น
Get-NetRoute -DestinationPrefix 10.24.0.0/16 | Select-Object DestinationPrefix,NextHop,InterfaceAlias
Resolve-DnsName files.corp.example.internal
Test-NetConnection -ComputerName 10.24.6.15 -Port 445ถ้าเส้นทางหายไป เซิร์ฟเวอร์ไม่ได้ดันมาหรือไคลเอนต์ทิ้งไป ถ้าเส้นทางมีอยู่และชื่อล้มเหลว ปัญหาอยู่ที่การแปลงชื่อ ถ้าทั้งสองทำงานและแอปพลิเคชันยังล้มเหลว คุณได้ผ่านอุโมงค์มาแล้วและอยู่ในคอนฟิกูเรชันของแอปพลิเคชันเอง
ให้การเปลี่ยนแปลงอยู่ที่ชั้นเดียวต่อการทดสอบ แต่ละการแก้ไขที่ทำก่อนความพยายามครั้งถัดไปจะกลายเป็นส่วนหนึ่งของบริบทของรหัสถัดไป และรหัสที่อธิบายการแก้ไขล่าสุดของคุณแย่กว่าไม่มีรหัสเลย
หนึ่งความพยายาม หนึ่งการเปลี่ยนแปลง หนึ่งบันทึก
ไม่ว่าจะเป็นขั้นตอนใด บันทึกควรมีรหัส ข้อความ ชื่อโปรไฟล์ ตราเวลา และเครือข่ายที่คุณอยู่ ห้าฟิลด์ และทุกฟิลด์อยู่ตรงหน้าคุณแล้วในกล่องโต้ตอบหรือบันทึกไคลเอนต์ ชุดนั้นเล็กพอที่จะวางในตั๋วและเฉพาะเจาะจงพอให้คนอื่นทำซ้ำได้
จากนั้นวางตราเวลานั้นข้างบันทึกของอีกฝั่ง ตารางใกล้ด้านบนของหน้านี้บอกว่าความไม่ตรงกันแต่ละอย่างเป็นของขั้นตอนใด หากไม่มีบันทึกที่สอง รหัสเพียงจำกัดการค้นหาให้แคบลง แต่เมื่อมีบันทึกนั้น ขั้นตอนก็ถูกตัดสิน การเปรียบเทียบคือสิ่งที่เปลี่ยนหมายเลขให้เป็นการวินิจฉัย ไม่ใช่การเดา
นิสัยนั้นครอบคลุมความผิดพลาด VPN แบบเนทีฟของ Windows เกือบทั้งหมด และไม่มีสาขาใดต้องติดตั้งอะไรใหม่ กล่องโต้ตอบบอกคุณมาตลอดว่าคุณมีอันไหน งานอยู่ที่การปฏิเสธที่จะถือว่าทั้งหมดเป็นปัญหาเดียวกัน