dev tun บน Windows ยังแสดงอะแดปเตอร์ TAP อยู่ นั่นผิดหรือไม่

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

ทำไมอุโมงค์เลเยอร์ 3 จึงได้อะแดปเตอร์ Ethernet

ตลอดประวัติ Windows ของไคลเอนต์ส่วนใหญ่ ไม่มีอะแดปเตอร์เสมือนเลเยอร์ 3 ที่ใช้งานได้ ทางเลือกเดียวคือไดรเวอร์ TAP-Windows ซึ่งนำเสนออินเทอร์เฟซ Ethernet จากนั้นไคลเอนต์จำลองพฤติกรรมเลเยอร์ 2 ที่ขาดหายไปเพื่อให้ Windows กำหนดค่าได้ การจำลองนั้นคือเหตุผลที่อะแดปเตอร์ยังดูเหมือนการ์ดเครือข่าย

สองส่วนของการจำลองนั้นมองเห็นได้หากสังเกต: ไคลเอนต์ตอบ ARP สำหรับที่อยู่ของอุโมงค์ และให้สัญญาเช่า DHCP ขนาดเล็กแก่เครื่องท้องถิ่น Windows จึงเห็นอะแดปเตอร์ Ethernet ปกติที่มีที่อยู่ MAC และไดรเวอร์ NDIS ขณะที่อุโมงค์เองบรรทุกแพ็กเก็ต IP เปล่า ชุด Ethernet เป็นของไดรเวอร์ ไม่ใช่ของโหมดอุโมงค์

หาบรรทัดไดรเวอร์แทนการตัดสินจากชื่อ

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

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

สลับไปใช้ไดรเวอร์เลเยอร์ 3 และตรวจว่าต้องมีอะไรอยู่

ไดรเวอร์เลเยอร์ 3 ที่โครงการ WireGuard จัดส่งมีให้ใช้ตั้งแต่ไคลเอนต์เวอร์ชัน 2.5 เป็นต้นไป แต่เป็นทางเลือก คำสั่งเดียวเลือกมัน:

windows-driver wintun

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

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

เมื่อใด TAP ยังเป็นคำตอบที่ถูก

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

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

ทำความสะอาดหลังการสลับ

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

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