ทำไม OpenVPN จึงหยุดเชื่อมต่อหลังอัปเกรด Ubuntu?

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

ชั้นใดล้มเหลว: การจับมือ ไซเฟอร์ แพ็กเกจ หรือไลบรารี

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

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

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

เมื่อการจับมือล้มเหลว นโยบาย TLS เป็นฝ่ายปฏิเสธใบรับรอง

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

การซ่อมแซมแบบแคบผูกสตริงไซเฟอร์กับเฉพาะการเชื่อมต่อนี้ เปิดโปรไฟล์ในตัวแก้ไขเดสก์ท็อป ไปที่การตั้งค่าขั้นสูง แล้วใส่ DEFAULT:@SECLEVEL=0 ในช่องไซเฟอร์ TLS ไฟล์คีย์ของ NetworkManager รับค่าเดียวกันภายใต้ [vpn]:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

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

OpenVPN 2.6 ต้องการให้ระบุไซเฟอร์สำหรับการเจรจา

Ubuntu 22.10 นำ OpenVPN 2.6 มา และในรุ่นนั้น --cipher หยุดเลือกช่องข้อมูลด้วยตัวเอง ไซเฟอร์ต้องอยู่ในรายการ data-ciphers ที่เจรจาด้วย ไม่อย่างนั้นไคลเอนต์จะพิมพ์คำเตือนเลิกใช้แล้วและจากนั้นก็ยกอุโมงค์ไม่ขึ้น

ปลั๊กอิน NetworkManager จากช่วงเดียวกันยังเขียนเฉพาะไดเรกทีฟเก่า รายละเอียดนี้แยกการวินิจฉัย เพราะโปรไฟล์ที่แก้ด้วยมืออาจเชื่อมต่อจากเชลล์ได้แต่ยังล้มเหลวจากแอปเพล็ตเดสก์ท็อป เพิ่มรายการลงในไฟล์การเชื่อมต่อภายใต้ [vpn]:

data-ciphers=AES-256-CBC

ใช้ค่าที่เซิร์ฟเวอร์ประกาศ ไม่ใช่ค่าที่คุณจำได้ เซิร์ฟเวอร์ที่เสนอ AES-256-GCM จะไม่เจรจากับรายการไคลเอนต์ที่ระบุเฉพาะ CBC รีสตาร์ตตัวจัดการแล้วเชื่อมต่อใหม่ จากนั้นทำซ้ำจากเชลล์โดยระบุไซเฟอร์อย่างชัดเจนทั้งสำหรับการเจรจาและทางเลือกสำรอง:

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

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

ข้อบกพร่องของแพ็กเกจและปลั๊กอินดูเหมือนข้อบกพร่อง VPN

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

อ่านข้อผิดพลาดของตัวจัดการแพ็กเกจก่อนบันทึก VPN ถ้าไคลเอนต์ไม่เคยถูกติดตั้ง การแก้โปรไฟล์มากเท่าไรก็ไม่เกิดการจับมือ

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

ไลบรารีของผู้ขายอาจซ่อนอยู่หลังข้อผิดพลาดนโยบาย

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

การติดตั้งแพ็กเกจ VPN ใหม่ไม่เปลี่ยนว่าไลบรารีใดถูกพบก่อน และการลดระดับ TLS ก็ไปไม่ถึงไลบรารีที่ไม่ได้มาจากระบบเลย ถามตัวโหลดว่าออบเจ็กต์การเข้ารหัสใดที่ไบนารีแก้จริง:

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

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

การปักหมุดไคลเอนต์เก่าซื้อเวลา ไม่ใช่ทางแก้

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

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

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