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

ตรวจสอบว่าเส้นทางชี้ไปที่ใดจริง ๆ

เริ่มด้วยการอ่านรายการเส้นทางและอะแดปเตอร์เคียงข้างกัน เส้นทางที่มีฮอปถัดไปบนอินเทอร์เฟซ VPN และมีดัชนีที่ไม่ตรงกับอะแดปเตอร์ปัจจุบันตัวใดเลยคือลายเซ็นของความล้มเหลวนี้ คำนำหน้าเดียวกันบนดัชนีอื่นอาจเป็นเศษเหลือหรือเส้นทางที่คุณต้องการจริง ๆ อ่านทั้งสองรายการก่อนจะเปลี่ยนรายการใด เพราะการเปรียบเทียบที่น่าสนใจคือระหว่างหมายเลขในเส้นทางกับหมายเลขที่มีอยู่ตอนนี้ หากดัชนีของเส้นทางปรากฏในรายการอะแดปเตอร์ แสดงว่าดัชนีไม่ใช่ปัญหาของคุณ และการค้นหาจะย้ายไปที่เมตริก นโยบาย หรือปลายทางไกล หากไม่ปรากฏ ก็ไม่มีอะไรต้องวินิจฉัยอีก เส้นทางผูกอยู่กับโครงสร้างพื้นฐานที่ไม่มีอยู่แล้ว

Get-NetRoute -DestinationPrefix '10.77.0.0/16' | Select-Object DestinationPrefix, NextHop, InterfaceIndex, Store
Get-NetAdapter | Where-Object InterfaceDescription -like '*VPN*' | Select-Object Name, InterfaceIndex, InterfaceDescription
Get-VpnConnection -Name 'Lab VPN' | Select-Object Name, ServerAddress, SplitTunneling

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

ผูกคำนำหน้ากับโปรไฟล์ ไม่ใช่กับอะแดปเตอร์

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

Add-VpnConnectionRoute -ConnectionName 'Lab VPN' -DestinationPrefix '10.77.0.0/16' -PassThru

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

ล้างเส้นทางเก่าก่อนเพิ่มเส้นทางใหม่

เส้นทางสองเส้นที่มีคำนำหน้าเดียวกันแต่เจ้าของต่างกันนั้นแย่กว่าเส้นทางผิดเพียงเส้นเดียว เพราะผู้ชนะขึ้นอยู่กับเมตริกที่ไม่มีใครบันทึกไว้ ตรวจดูว่ามีอะไรอยู่แล้วสำหรับคำนำหน้านี้ รวมถึงรายการในที่เก็บถาวร และลบเฉพาะสิ่งที่อยู่ในการพยายามที่ล้มเหลว เศษเหลือจากการออกแบบเดิมเป็นเรื่องปกติในด้านนี้ เพราะเส้นทางที่ล้มเหลวมักแทนที่สิ่งที่เคยทำงานได้ บันทึกว่ารายการใดเป็นของการเชื่อมต่อใดก่อนจะลบสิ่งใด และเก็บรายการไว้ในบันทึกการเปลี่ยนแปลง

Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like '10.77.*'
Remove-NetRoute -DestinationPrefix '10.77.0.0/16' -NextHop '0.0.0.0' -Confirm:$false

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

เชื่อมต่อใหม่ในลำดับที่ต่างออกไป

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

rasdial 'Lab VPN' /disconnect
rasdial 'Lab VPN'
Find-NetRoute -RemoteIPAddress 10.77.5.20 | Select-Object -First 1

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

รู้ว่าเส้นทางทำอะไรไม่ได้

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

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

บทความที่เกี่ยวข้อง