TUN/TAP: อาร์กิวเมนต์ไม่ถูกต้อง — การจัดเฟรม OpenVPN ไม่ตรงกัน

ไคลเอนต์ผ่านการพิสูจน์ตัวตน บันทึกบอกว่าเชื่อมต่อแล้ว และไม่มีแพ็กเก็ตใดข้ามอุโมงค์ เซิร์ฟเวอร์จบความพยายามด้วย write to TUN/TAP: Invalid argument (code=22) ซึ่งดูเหมือนความผิดพลาดของไดรเวอร์และมักไม่ใช่ บนเราเตอร์และเซิร์ฟเวอร์ Linux ขนาดเล็ก บรรทัดนั้นมักหมายความว่าสองฝั่งไม่ตกลงกันเรื่องวิธีจัดเฟรมแพ็กเก็ตข้อมูล เคอร์เนลจึงปฏิเสธบัฟเฟอร์ที่ถอดรหัสแล้วซึ่งส่งให้ การกำหนดเส้นทางยังไม่ได้ทดสอบ ณ จุดนั้น

ตารางเส้นทางที่ถูกต้องกับข้อตกลงการจัดเฟรมที่เสียดูเหมือนกันจากฝั่งไคลเอนต์ คือเชื่อมต่อแล้วแต่ไม่มีอะไรทำงาน

อุโมงค์ขึ้นมาแต่ไม่มีอะไรข้ามผ่าน

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

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

การบีบอัดคือการจัดเฟรม ไม่ใช่แบนด์วิดท์

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

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

จัดทั้งสองฝั่งให้ตรงกันหรือเอาออกทั้งสองฝั่ง

แจกแจงทุกคำสั่งการบีบอัด ไฟล์เซิร์ฟเวอร์ ตัวเลือกที่พุชมา ไฟล์เฉพาะไคลเอนต์ และโปรไฟล์ไคลเอนต์ comp-lzo บนเซิร์ฟเวอร์ต้องมีคำเดียวกันบนไคลเอนต์ และ adaptive คือค่าเริ่มต้นแบบเดิมที่ตัวเลือกเปล่ามักหมายถึงในบิลด์เก่า สวิตช์ GUI ของเราเตอร์ที่ติดป้าย LZO หรือการบีบอัดเขียนตัวเลือกเดียวกัน ดังนั้นตั้งให้ตรงกันแทนการผสมอัลกอริทึม อย่าสันนิษฐานว่าชื่อที่คล้ายกันจะเข้ากันได้

ถ้าไม่ต้องการการบีบอัด ให้เอาออกอย่างตั้งใจจากทั้งสองฝั่ง allow-compression no บนเซิร์ฟเวอร์ปฏิเสธแพ็กเก็ตที่บีบอัด แต่เฉพาะเมื่อไคลเอนต์เลิกเสนอแล้วเท่านั้น การใช้ในขณะที่ไคลเอนต์ยังพุชการบีบอัดจะสร้างความไม่ตรงกันในทิศทางกลับกันอีกครั้ง

ตรวจสอบการพุชและประเภทอุปกรณ์

เซิร์ฟเวอร์สามารถพุชคำสั่งการบีบอัดจากไฟล์หลักหรือไฟล์เฉพาะไคลเอนต์ และไคลเอนต์สามารถทิ้งตัวเลือกที่พุชมาด้วย pull-filter เชื่อมต่อไคลเอนต์หนึ่งตัวที่ระดับรายละเอียด 4 อ่านสิ่งที่เซิร์ฟเวอร์ประกาศเทียบกับสิ่งที่ไคลเอนต์ยอมรับ แล้วยืนยันว่าไม่มีตัวกรองใดเอาออก หากทั้งสองฝั่งตกลงกันแล้วแต่ข้อผิดพลาดยังอยู่ ดูประเภทอุปกรณ์: dev tap ที่ฝั่งหนึ่งและ dev tun ที่อีกฝั่งแลกเปลี่ยนเฟรมไม่ได้ และเคอร์เนลก็ปฏิเสธการเขียนเช่นเดียวกัน

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

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