การลบ key-method ออกจากโปรไฟล์ OpenVPN ไม่ได้เปลี่ยนอะไร

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

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

อาการคือข้อผิดพลาดในการแยกวิเคราะห์ ไม่ใช่การจับมือล้มเหลว

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

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

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

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

คำสั่งและรูปแบบการส่งเป็นสองสิ่งที่แตกต่างกัน

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

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

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

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

จะลบอะไร และจากไฟล์ไหน

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

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

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

โปรไฟล์ที่ถูกปฏิเสธและไคลเอนต์ที่ถูกปฏิเสธดูคล้ายกัน

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

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

คำถามเรื่องความเข้ากันได้ที่บรรทัดนั้นไม่เคยตอบ

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

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

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