ข้อผิดพลาด OpenVPN: ตัวเลือกที่ไม่รู้จัก tls-remote หรือ keysize

โดยปกติเรื่องนี้เริ่มจากโปรไฟล์ที่เชื่อมต่อมาหลายปี ถูกเปิดในไคลเอนต์รุ่นใหม่กว่า แล้วล้มเหลวก่อนที่อุโมงค์จะเริ่มทำงานด้วยซ้ำ เทอร์มินัลพิมพ์ข้อความประมาณ Options error: Unrecognized option ... in client.ovpn:130: tls-remote พร้อมหมายเลขเวอร์ชันในวงเล็บตอนท้าย อ่านมันเป็นคำบ่นของตัวแยกวิเคราะห์ได้เลย: ไฟล์มีคำสั่งที่ไคลเอนต์นี้ไม่รู้จักอีกต่อไป

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

อ่านบรรทัดที่ล้มเหลวก่อนแก้ไขอะไร

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

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

เกิดอะไรขึ้นกับ keysize และ tls-remote

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

tls-remote ถูกนำออกในเวอร์ชัน 2.4 มันเคยเปรียบเทียบใบรับรองเซิร์ฟเวอร์กับชื่อที่คาดไว้ และคำสั่งที่มาแทนคือ verify-x509-name ซึ่งเข้มงวดกว่าวิธีจับคู่ชื่อ คำสั่งเก่าหมดไปแล้ว โปรไฟล์ที่ยังมีคำสั่งนี้จึงไม่มีวันถูกแยกวิเคราะห์บนไคลเอนต์ปัจจุบัน

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

เขียนการตรวจสอบตัวตนเซิร์ฟเวอร์ใหม่

คำสั่งแทนรับชื่อที่คาดไว้และโหมดการเปรียบเทียบ verify-x509-name vpn.example.edu name กำหนดให้ subject ของใบรับรองตรงกับค่านั้นพอดี โหมดอื่นจับคู่คำนำหน้าหรือสตริง subject ทั้งหมด และการเลือกโหมดผิดจะเปลี่ยนโปรไฟล์ที่ใช้งานได้ให้กลายเป็นความล้มเหลวในการยืนยันที่สะอาด

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

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

โปรไฟล์ที่แก้แล้ว การแก้ไขในเครื่อง หรือไคลเอนต์รุ่นเก่า

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

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

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

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