ทำไมการเพิ่ม opt-verify จึงไม่แก้ไขข้อผิดพลาดการเข้ารหัสของ OpenVPN

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

การรู้ว่าบรรทัดนั้นเคยทำอะไรช่วยได้ ก่อนจะสรุปว่ามันคือชิ้นส่วนที่ขาดหาย ประวัติยังอธิบายว่าทำไมตอนนี้มันช่วยไม่ได้

สิ่งที่ตัวเลือกเคยบังคับ

คู่มือ 2.6 ระบุว่า opt-verify เลิกใช้แล้วและอธิบายพฤติกรรมเดิม: เซิร์ฟเวอร์ตัดไคลเอนต์ที่ตัวเลือกซึ่งประกาศไว้ไม่ตรงกับของตัวเอง โดยเปรียบเทียบสิ่งอย่างประเภทอุปกรณ์และ MTU การตรวจสอบนั้นยังขึ้นอยู่กับการตรวจสอบความสอดคล้องของตัวเลือกที่ยังเปิดอยู่ ดังนั้นเซิร์ฟเวอร์ที่รันด้วย disable-occ จึงไม่เคยมีมันตั้งแต่แรก สังเกตว่าการเปรียบเทียบสร้างจากอะไร: ข้อความที่อธิบายการกำหนดค่าของอีกฝ่าย มันไม่ได้บอกอะไรเกี่ยวกับการเข้ารหัสที่ช่องข้อมูลจะใช้

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

2.7 ทำอะไรเมื่อเห็นบรรทัดนั้น

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

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

ความล้มเหลวอยู่ที่ไหนจริง ๆ

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

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

แทนที่เจตนา ไม่ใช่แค่บรรทัด

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

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

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

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