ทำไมไคลเอนต์ Linux ของ GlobalProtect จึงล้มเหลวบน Ubuntu ที่ใหม่กว่า

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

.deb ไม่ได้เสีย

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

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

ยืนยัน dependence แทนที่จะบังคับมัน

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

sudo apt install ./GlobalProtect_UI_deb-*.deb
apt-cache policy libqt5webkit5
apt-cache rdepends --installed libqt5webkit5

ถ้า apt-cache policy ไม่รายงานผู้สมัครเลย ให้เลิกพยายามติดตั้งแล้วเริ่มเลือกทางเลือกอื่น ที่น่าสนใจไม่ใช่ชื่อแพ็กเกจที่หายไป แต่เป็นข้อเท็จจริงที่กราฟ dependence ของผู้ขายไม่ได้ขยับไปพร้อมดิสทริบิวชันที่ผู้ใช้ของคุณใช้งาน

การบังคับแพ็กเกจเก่าทำอะไรกับเดสก์ท็อป

วิธีเลี่ยงที่แพร่หลายคือดึงไลบรารีจากรุ่นเก่ากว่า บน Ubuntu ปัจจุบันสิ่งนั้นไปจบที่ความขัดแย้งของ minor version ของ Qt5: แพ็กเกจเก่าดึง libqt5core5t64 ถอยหลัง แล้วแพ็กเกจ KDE และ PyQt ที่ติดตั้งอยู่เริ่มเรียกหา ABI version ที่ไลบรารีที่ถูกลดรุ่นไม่ได้ให้แล้ว ผลลัพธ์คือการอัปเกรดบางส่วนที่ทำให้แอปพลิเคชันที่ไม่เกี่ยวข้องพัง ซึ่งเป็นบ่ายที่แย่กว่ามาก

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

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

openconnect พูดโปรโตคอลนี้

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

openconnect --protocol=gp vpn.example.com
openconnect --protocol=gp --authgroup=staff vpn.example.com

ถ้าพอร์ทัลไม่ระบุเกตเวย์ที่คุณต้องการ --usergroup=gateway หรือ URL ที่ลงท้ายด้วย /gateway จะข้ามขั้นตอนพอร์ทัล เมื่อมีเกตเวย์หลายตัว --authgroup=NAME จะเลือกจากที่มี การพิสูจน์ตัวตนคือชื่อผู้ใช้และรหัสผ่าน เสริมด้วยใบรับรองไคลเอนต์ได้ และเกตเวย์ SAML ในทางปฏิบัติทำงานผ่าน network-manager-openconnect แทนที่จะเป็นบรรทัดคำสั่งที่พิมพ์ด้วยมือ

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

ตรวจสอบอุโมงค์ และรู้ว่า openconnect ไม่แก้อะไร

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

ip -4 addr show
ip route
resolvectl status

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

IPv6 เป็นอีกเรื่อง PAN เพิ่มมันใน GlobalProtect 4.0 และการรองรับของ OpenConnect ถูกอธิบายว่าเป็นการทดลองตั้งแต่เวอร์ชัน 9.0 ดังนั้นอย่าคิดว่าตระกูลที่อยู่จะทำงานเหมือน IPv4 เพียงเพราะอุโมงค์ขึ้นมา ถ้าเกตเวย์บังคับตรวจ posture ที่ไคลเอนต์โอเพนซอร์สทำไม่ได้ ให้รันไคลเอนต์ของผู้ขายบน LTS ที่รองรับ ในเครื่องเสมือนถ้าสถานีงานของคุณไปข้างหน้าแล้ว นั่นรักษาเดสก์ท็อปไว้และวาง dependence เก่าไว้ในขอบเขตที่คุณสร้างใหม่ได้