SNX trên Linux: thư viện 32-bit và trình phân giải tự đặt lại
SNX trên Linux thất bại ở bộ nạp, bảng định tuyến hoặc trình phân giải, và mỗi lỗi đều trông như vấn đề đăng nhập. Xử lý bốn triệu chứng theo thứ tự.
SSL Network Extender của Check Point thất bại trên Linux theo bốn cách dễ nhận ra, và ba trong số đó bị đọc nhầm thành vấn đề đăng nhập. Hoặc tệp nhị phân không khởi động, hoặc khởi động mà không để lại tuyến nào, hoặc kết nối rồi việc phân giải tên chết, hoặc cổng thông tin trên trình duyệt hoạt động trong khi dòng lệnh thì không. Hãy xử lý theo thứ tự đó, vì mỗi cái là điều kiện vào của cái tiếp theo.
Triệu chứng một: bộ nạp từ chối trước khi đăng nhập
Trình cài đặt lấy từ tường lửa đặt một tệp nhị phân 32-bit có setuid-root vào /usr/bin/snx. Trên bản phân phối 64-bit, nó không chạy cho đến khi kiến trúc i386 được bật và các thư viện mà nó liên kết tồn tại.
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"Danh sách not found rỗng là cổng cho mọi thứ sau đó. Bộ gói chính xác thay đổi giữa các bản phát hành: một báo cáo chạy được cần libstdc++5:i386, libx11-6:i386 và libpam0g:i386, báo cáo khác cũng cần libstdc++6:i386. Hãy đọc ldd thay vì sao chép danh sách gói từ hướng dẫn viết cho bản phân phối khác.
Nếu hoàn toàn không tìm thấy snx, trình cài đặt chưa bao giờ hoàn tất hoặc đã cài đặt ở đâu đó ngoài PATH của bạn. Đó là một lỗi khác, và đáng để xác nhận trước khi thêm kiến trúc vào hệ thống. Hãy kiểm tra bằng command -v snx và xem trong thư mục mà trình cài đặt đã báo. Thêm gói i386 vào một máy hoàn toàn không có tệp nhị phân thì không sửa được gì.
Triệu chứng hai: đăng nhập thành công và không có gì được định tuyến
Đăng nhập thành công tạo ra tunsnx và tự sửa bảng định tuyến, nên hãy kiểm tra thực tế có gì trước khi thay đổi bất cứ điều gì khác.
ip -br addr show tunsnx
ip route | grep tunsnx
snx -dDùng snx -d để tháo gỡ. Giết tiến trình để lại giao diện và các tuyến của nó, và lần thử tiếp theo sau đó thất bại vì lý do không liên quan gì đến thông tin đăng nhập. Lần đăng nhập đầu tiên cũng ghi chữ ký máy chủ dưới /etc/snx/, đó là lý do một tập lệnh không giám sát có thể cần một lần chạy tương tác trước khi nó hoạt động được. Chỉ xóa trạng thái đó khi bạn định phê duyệt máy chủ lại.
Triệu chứng ba: tên được phân giải cho đến khi đường hầm đi lên
Đây là cái âm thầm hỏng. snx ghi các máy chủ DNS được đẩy thẳng vào /etc/resolv.conf. Ở nơi đường dẫn đó là một liên kết tượng trưng vào /run/systemd/resolve/, bản sửa có thể mất ở sự kiện trình phân giải tiếp theo, và sau khi ngắt kết nối các mục được đẩy cũng có thể ở lại.
Có hai cách sắp xếp hiệu quả, và lựa chọn nên có chủ đích chứ không phải điều mà kết quả tìm kiếm đầu tiên gợi ý:
- Nắm lấy tệp: thay liên kết tượng trưng bằng tệp tĩnh và cài
libnss-resolvecùng biến thể i386 của nó, để dịch vụ tên vẫn có phương án dự phòng khi tệp bị ghi lại bên dưới. - Giữ systemd-resolved làm chủ sở hữu và đăng ký liên kết đường hầm:
resolvectl dns tunsnx 10.0.0.10, sau đóresolvectl domain tunsnx corp.example, và xác nhận bằngresolvectl status.
Ghi lại các máy chủ tên trước VPN trước khi kết nối. Nếu bạn sửa tệp bằng tay, việc gỡ các mục được đẩy sau đó là một phần của quy trình, không phải dọn dẹp tùy chọn, vì một máy tính xách tay giữ DNS doanh nghiệp sau khi ngắt kết nối sẽ không phân giải được gì khác.
Triệu chứng bốn: cổng thông tin hoạt động và CLI thì không
Các bản phát hành tường lửa gần đây đã chuyển phần mềm trung gian khỏi trình duyệt sang một daemon Java cục bộ, nên cổng thông tin nói chuyện với một tác nhân cục bộ trên cổng 14186. Địa chỉ đó cần một ngoại lệ chứng chỉ trong trình duyệt và một tiến trình đang chạy.
ps ax | grep cshell
/usr/bin/cshell/launcherDòng lệnh là một đường riêng: snx -s vpn.example.com -u user, với ~/.snxrc giữ máy chủ, tên người dùng và tùy chọn xác thực lại. Một phiên cổng thông tin đang hoạt động không nói gì về việc CLI có được cài đặt đúng hay không, và ứng dụng khách trần không xử lý mã dùng một lần.
Lối tắt bằng vùng chứa tốn kém hơn mức tiết kiệm
snx kiểm tra mô-đun tun, nạp nó khi thiếu, tạo giao diện đường hầm, ghi lại các tuyến và đẩy lưu lượng qua nó. Tái tạo điều đó trong một vùng chứa nghĩa là gắn /dev và /lib/modules và cấp quyền rộng, điều này trao cho vùng chứa phần lớn việc quản trị mạng của máy chủ.
Khi thực sự cần một hộp cát, máy ảo là ranh giới sạch hơn: ứng dụng khách nhận một nhân mà nó có thể sửa đổi, và máy chủ giữ bảng định tuyến của nó. Hãy chọn điều đó trước khi dành một buổi chiều cho những quyền mà bạn sẽ hối tiếc vì đã cấp.