AWS Client VPN ไม่เปิดบน Linux? จับคู่รันไทม์ให้ตรง

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

ข้อผิดพลาดระบุชื่อไลบรารี ไม่ใช่เครือข่าย

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

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

ทั้งสองจบลงด้วยหน้าต่างที่ปิดลง นั่นคือเหตุผลที่พวกมันถูกปนกันในรายงานข้อบกพร่อง

สวิตช์โลกาภิวัตน์เป็นปัญหาอีกอย่าง

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

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

ถ้าโฮสต์ให้รันไทม์ที่ต้องการไม่ได้จริง ๆ คำตอบที่รองรับคือโฮสต์อื่น ไม่ใช่โฮสต์ที่ดัดแปลง

ทำไมการนำเข้า OpenSSL เก่าจึงย้อนกลับมาทำร้าย

การคัดลอก libssl และ libcrypto จากดิสทริบิวชันที่เก่ากว่าไปยัง /usr/lib ทำงานได้บ่อยพอที่จะชวนให้ทำ นอกจากนี้ยังวางไลบรารีไว้นอกการควบคุมของตัวจัดการแพ็กเกจ ดังนั้นการอัปเดตความปลอดภัยทุกครั้งหลังจากนั้นจึงพลาดมันไปหรือชนกับมัน บนโฮสต์ที่รันเบราว์เซอร์หรือไคลเอนต์ SSH ด้วย คุณได้เปลี่ยนสแตกการเข้ารหัสลับสำหรับโปรแกรมที่ไม่เคยขอ

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

วิธีแก้จากฟอรัมเก่า ๆ คือภาพนิ่งของคู่รุ่นหนึ่ง ไม่ใช่การรับประกันความเข้ากันได้

รักษานิยามบริการของผู้จำหน่าย

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

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

เขียนเส้นทางของไฟล์เขียนทับลงในบันทึกของคุณ เพราะผู้ดูแลระบบคนต่อไปจะดูที่นั่นก่อน

พิสูจน์การเปิดก่อนที่จะดีบักเส้นทาง

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

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

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