OpenVPN data-ciphers เลือกไซเฟอร์ของช่องข้อมูลอย่างไร

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

สองช่อง สองการกำหนดค่า

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

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

เก็บทั้งสามไว้ในกล่องของตัวเองเมื่อคุณอ่านไฟล์กำหนดค่า

อ่านการเจรจาจากบันทึก

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

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

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

การเลือกเกิดขึ้นจริงอย่างไร

เซิร์ฟเวอร์ผลักรายการ data-ciphers ของตนไปยังไคลเอนต์ระหว่างแฮนด์เชก และไคลเอนต์เลือกรายการแรกในรายการนั้นที่ตนรองรับด้วย ดังนั้นลำดับจึงเป็นของการกำหนดค่าเซิร์ฟเวอร์ ไม่ใช่ของไคลเอนต์

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

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

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

คู่ตรงข้ามรุ่นเก่าต้องการทางสำรองที่ตั้งใจไว้

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

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

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

รักษาการตรวจสอบให้สมบูรณ์

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

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

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

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