Check Point VPN บน Linux: SNX ไม่ใช่ไฟล์ที่ดาวน์โหลดมาติดตั้ง

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

ความเชื่อผิด: มีลูกค้าที่คุณดาวน์โหลดและติดตั้ง

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

มิเรอร์เหล่านั้นแย่กว่าไร้ประโยชน์ เพราะบิลด์ต้องตรงกับเกตเวย์ที่ให้บริการมัน

SNX จริง ๆ คืออะไร และมาจากไหน

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

นี่ยังหมายความว่าเกตเวย์ต้องพร้อมก่อนที่งานใด ๆ ฝั่งลูกค้าจะมีความหมาย Mobile Access Software Blade ต้องได้รับไลเซนส์และกำหนดค่า เพราะหากไม่มีก็ไม่มีพอร์ทัลให้ติดตั้ง ไม่มีความพยายามใดฝั่งลูกค้าจะสร้างเซสชันกับเกตเวย์ที่ไม่เสนอให้ได้

ชี้ลูกค้าไปที่เกตเวย์ด้วยผู้ใช้ของคุณ แล้วอ่านว่ามันรายงานอะไร:

snx -s vpn.example.com -u your.name

ข้อจำกัดคือการรองรับดิสทริบิวชัน ไม่ใช่ตัวติดตั้ง

รายการดิสทริบิวชันที่ผู้จำหน่ายรองรับสำหรับ SNX นั้นสั้นและเก่า ในบทความที่เผยแพร่ มันหยุดราว Ubuntu 17.04 พร้อมกับรุ่น openSUSE Fedora และ RHEL จากยุคเดียวกันสองสามรุ่น และยังระบุ Ubuntu 12.10 อยู่ สิ่งนี้บอกว่ารายการนั้นเก่าเร็วแค่ไหน ไม่ได้บอกว่าเครื่องของคุณต้องการอะไร ดิสทริบิวชันปัจจุบันไม่มีอยู่ในนั้นเลย

คาดว่าจะเจอไลบรารีไม่ตรงกันก่อนจะได้อุโมงค์ที่ใช้งานได้ สามข้อที่พบบ่อยคือไลบรารี 32 บิตที่ขาดหายบนระบบ 64 บิต เวอร์ชัน OpenSSL ที่ไบนารีไม่เคยลิงก์ด้วย และโมดูลเคอร์เนลที่ลูกค้าพยายามบิลด์ อ่านสัญลักษณ์ที่ขาดแทนการเดาแพ็กเกจ:

ldd $(command -v snx) | grep "not found"

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

รายละเอียด X11 ที่ทำให้ทำงานได้โดยไม่มีหน้าจอ

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

หลังจากเชื่อมต่อแล้วอ่านอินเทอร์เฟซและเส้นทางก่อนจะเชื่อถือทั้งสองอย่าง:

ip -brief addr show
ip route show

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

เมื่อ SNX เป็นคำตอบที่ผิดทั้งหมด

เกตเวย์ Check Point ยังยุติการเชื่อมต่อ IPsec และL2TPจากลูกค้าไปยังไซต์ได้ด้วย และสิ่งเหล่านั้นทำงานกับ strongSwan Libreswan หรือปลั๊กอิน L2TP ของ NetworkManager นั่นคือการกำหนดค่าเกตเวย์ ไม่ใช่กลลวงฝั่งลูกค้า หากเกตเวย์เปิดเผยเฉพาะพอร์ทัล Mobile Accessลูกค้า IPsec ก็ไม่มีอะไรให้เจรจาและบันทึกจะแสดงการหมดเวลาแทนความล้มเหลวในการยืนยันตัวตน ถามว่าบล็อกสำหรับการเข้าถึงระยะไกลตัวใดเปิดใช้งานก่อนติดตั้งอย่างอื่น

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