SNX บน Linux: ไลบรารี 32 บิตและตัวแก้ชื่อที่รีเซ็ตตัวเอง

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

อาการที่หนึ่ง: ตัวโหลดปฏิเสธก่อนการเข้าสู่ระบบ

ตัวติดตั้งที่ดึงจากไฟร์วอลล์วาง ไบนารี 32 บิตที่มี setuid-root ไว้ที่ /usr/bin/snx บนดิสทริบิวชัน 64 บิต มันไม่ทำงานจนกว่าสถาปัตยกรรม i386 จะถูกเปิดใช้งานและไลบรารีที่มันลิงก์ด้วยมีอยู่

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libstdc++5:i386 libstdc++6:i386 libx11-6:i386 libpam0g:i386
ldd /usr/bin/snx | grep "not found"

รายการ not found ที่ว่างเปล่าคือประตูสำหรับทุกสิ่งหลังจากนั้น ชุดแพ็กเกจที่แน่นอนเปลี่ยนไประหว่างรุ่น: รายงานที่ใช้งานได้ชิ้นหนึ่งต้องการ libstdc++5:i386, libx11-6:i386 และ libpam0g:i386 อีกชิ้นต้องการ libstdc++6:i386 ด้วย อ่าน ldd แทนที่จะคัดลอกรายการแพ็กเกจจากบทช่วยสอนที่เขียนสำหรับดิสทริบิวชันอื่น

ถ้าไม่พบ snx เลย ตัวติดตั้งทำงานไม่เสร็จหรือติดตั้งไว้ที่อื่นนอก PATH ของคุณ นั่นเป็นความล้มเหลวอีกแบบ และควรยืนยันก่อนเพิ่มสถาปัตยกรรมลงในระบบ ตรวจสอบด้วย command -v snx และดูในไดเรกทอรีที่ตัวติดตั้งรายงาน การเพิ่มแพ็กเกจ i386 บนเครื่องที่ไม่มีไบนารีอยู่เลยไม่ช่วยแก้ไขอะไร

อาการที่สอง: การเข้าสู่ระบบสำเร็จและไม่มีอะไรถูกกำหนดเส้นทาง

การเข้าสู่ระบบที่สำเร็จจะสร้าง tunsnx และแก้ไขตารางเส้นทางเอง ดังนั้นตรวจสอบว่ามีอะไรอยู่จริงก่อนเปลี่ยนสิ่งอื่น

ip -br addr show tunsnx
ip route | grep tunsnx
snx -d

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

อาการที่สาม: ชื่อถูกแก้ได้จนกว่าอุโมงค์จะขึ้น

นี่คืออันที่พังเงียบ ๆ snx เขียนเซิร์ฟเวอร์ DNS ที่ถูกดันลงใน /etc/resolv.conf โดยตรง เมื่อเส้นทางนั้นเป็นซิมโบลิกสิงก์เข้าไปใน /run/systemd/resolve/ การแก้ไขอาจสูญหายในเหตุการณ์ตัวแก้ชื่อครั้งถัดไป และหลังตัดการเชื่อมต่อรายการที่ถูกดันก็อาจคงอยู่ได้เช่นกัน

มีสองวิธีที่ได้ผล และการเลือกควรเป็นไปอย่างตั้งใจ ไม่ใช่สิ่งที่ผลการค้นหาอันแรกเสนอ:

• เข้าครอบครองไฟล์: แทนที่ซิมโบลิกสิงก์ด้วยไฟล์แบบคงที่และติดตั้ง libnss-resolve พร้อมรุ่น i386 ของมัน เพื่อให้บริการชื่อยังมีทางสำรองเมื่อไฟล์ถูกเขียนทับข้างใต้
• เก็บ systemd-resolved เป็นเจ้าของและลงทะเบียนลิงก์อุโมงค์: resolvectl dns tunsnx 10.0.0.10 จากนั้น resolvectl domain tunsnx corp.example และยืนยันด้วย resolvectl status

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

อาการที่สี่: พอร์ทัลทำงานแต่ CLI ไม่ทำงาน

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

ps ax | grep cshell
/usr/bin/cshell/launcher

บรรทัดคำสั่งเป็นเส้นทางแยก: snx -s vpn.example.com -u user โดย ~/.snxrc เก็บเซิร์ฟเวอร์ ชื่อผู้ใช้ และการตั้งค่าการยืนยันตัวตนซ้ำ เซสชันพอร์ทัลที่ทำงานไม่ได้บอกอะไรเกี่ยวกับการติดตั้ง CLI ที่ถูกต้อง และไคลเอนต์เปล่าไม่จัดการรหัสใช้ครั้งเดียว

ทางลัดของคอนเทนเนอร์ที่แพงกว่าที่ประหยัดได้

snx ตรวจสอบโมดูล tun โหลดเมื่อไม่มี สร้างอินเทอร์เฟซอุโมงค์ เขียนเส้นทางใหม่ และดันทราฟฟิกผ่านมัน การจำลองสิ่งนี้ในคอนเทนเนอร์หมายถึงการเมานต์ /dev และ /lib/modules และ ให้ความสามารถกว้างขวาง ซึ่งมอบการจัดการเครือข่ายส่วนใหญ่ของโฮสต์ให้คอนเทนเนอร์

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