OpenVPN Connect ปฏิเสธ fragment: แก้ต้นทางของโปรไฟล์

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

การลบบรรทัดนั้นทำให้ได้ไฟล์ที่ไคลเอนต์จะแยกวิเคราะห์ และเซิร์ฟเวอร์ที่อาจยังคาดหวังรูปแบบที่บรรทัดนั้นอธิบายไว้ ไล่ดูจากหน้าจอนำเข้าออกไปก่อนจะแก้อะไร

การนำเข้าหยุดตรงไหน

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

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

fragment เปลี่ยนอะไรในไคลเอนต์ชุมชน

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

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

ขอโปรไฟล์ที่สร้างสำหรับไคลเอนต์นี้

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

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

ตรวจสอบการเชื่อมต่อ ไม่ใช่แค่การนำเข้า

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

openvpn --config client.ovpn --verb 3
ip -4 addr show tun0
curl -sS --interface tun0 -o /dev/null -w '%{http_code}\n' --max-time 8 https://example.com/

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

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