Vì sao ứng dụng Linux của GlobalProtect thất bại trên Ubuntu mới hơn

Giả định hợp lý là tệp .deb từ cổng GlobalProtect của bạn bị hỏng, hoặc nhà cung cấp đã phát hành một bản dựng lỗi. Thường thì không phải. Giao diện Linux của nhà cung cấp vẫn liên kết với Qt5 WebKit, và các bản Ubuntu mới hơn không còn cung cấp nó nữa, nên gói đang yêu cầu một thư viện mà bản phân phối của bạn đã cố ý gỡ bỏ. Đó là sự không khớp về đóng gói, không phải bản tải xuống bị hỏng, và khác biệt đó quyết định việc bạn dành cả buổi chiều ép gói hay mười phút chọn một ứng dụng khác.

Tệp .deb không hỏng

Một phụ thuộc mà bản phân phối không còn mang theo là kết quả bình thường của việc một thư viện bị ngừng cung cấp. Qt5 WebKit đã bị gỡ khỏi các kho lưu trữ Ubuntu về sau và khỏi Debian, và lý do là việc bảo trì bảo mật chứ không phải thiếu nhu cầu. Khi điều đó xảy ra, mọi gói còn liên kết tới nó sẽ không còn cài được nữa, dù nó được dựng tốt đến đâu.

Hai lỗi được báo cáo như cùng một bug và không phải vậy. Trên một bản phát hành không có thư viện, trình cài đặt dừng lại ở một phụ thuộc không được đáp ứng. Trên một bản phát hành nơi ứng dụng cài được rồi hỏng khi đăng nhập, bạn đang thấy một vấn đề bắt tay TLS hoặc SAML bên trong thành phần trình duyệt nhúng. Cái đầu là đóng gói; cái sau là thời gian chạy, và không cái nào được sửa bằng cách chép thư viện cũ vào một máy tính để bàn hiện đại.

Xác nhận phụ thuộc thay vì ép buộc nó

Hãy cài gói một cách tường minh để công cụ nêu tên phụ thuộc chưa được giải quyết thay vì cho bạn một bản tóm tắt. Sau đó hỏi xem bản phát hành của bạn có ứng viên nào không, vì „không có sẵn ở đây” và „tạm thời thiếu khỏi bản sao này” dẫn tới những quyết định hoàn toàn khác nhau:

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

Nếu apt-cache policy không báo cáo ứng viên nào, hãy ngừng cố cài nó và bắt đầu chọn một phương án khác. Điều đáng chú ý không phải tên gói bị thiếu; mà là việc đồ thị phụ thuộc của nhà cung cấp không di chuyển cùng các bản phân phối mà người dùng của bạn đang chạy.

Việc ép gói cũ gây ra gì cho máy tính để bàn

Cách lách đang lan truyền là lấy thư viện từ một bản phát hành cũ hơn. Trên một Ubuntu hiện hành, việc đó dẫn tới xung đột phiên bản phụ của Qt5: các gói cũ kéo libqt5core5t64 ngược lại, và rồi các gói KDE và PyQt đã cài bắt đầu đòi một phiên bản ABI mà thư viện bị hạ cấp không còn cung cấp. Kết quả là một lần nâng cấp từng phần làm hỏng những ứng dụng không liên quan, tức một buổi chiều tệ hơn nhiều so với buổi chiều bạn bắt đầu.

Kết quả đó là đáng lường trước chứ không phải xui xẻo. Kỳ vọng ABI của Qt với các phiên bản phụ rất nghiêm ngặt, và một bản phân phối cung cấp một bộ nhất quán. Trộn một thư viện từ bản phát hành khác vào không phải là một bản sửa có mục tiêu; đó là lần nâng cấp thứ hai, ít được kiểm soát hơn.

Lời khuyên tương tự áp dụng cho biến thể lỗi lúc chạy. Hạ mức bảo mật của OpenSSL trên toàn hệ thống để cuộc bắt tay của một ứng dụng cũ thành công sẽ thay đổi mọi kết nối TLS trên máy để sửa một ứng dụng, kể cả trình quản lý gói mà bạn sẽ cần khi có thứ khác hỏng.

openconnect nói giao thức đó

OpenConnect tự triển khai giao thức của GlobalProtect, và ghi chú giao thức mô tả cả cách gọi lẫn sự phân chia giữa hai giao diện máy chủ. Cổng phân phối cấu hình và danh sách cổng ra; cổng ra kết thúc đường hầm:

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

Nếu cổng không liệt kê cổng ra mà bạn cần, --usergroup=gateway hoặc một URL kết thúc bằng /gateway sẽ bỏ qua bước cổng. Khi có nhiều cổng ra được đưa ra, --authgroup=NAME sẽ chọn trong số đó. Xác thực là tên người dùng và mật khẩu, tùy chọn kèm chứng chỉ máy khách, và các cổng ra SAML trên thực tế hoạt động qua network-manager-openconnect chứ không phải một dòng lệnh gõ tay.

Một cổng ra có chính sách posture nghiêm ngặt cũng có thể yêu cầu một báo cáo HIP trước khi cấp đường hầm. OpenConnect tạo và gửi được một báo cáo như vậy, nhưng nếu cổng ra đòi một bản kiểm kê mà nó không thể tạo, không cờ nào thay đổi chính sách đó; đó là quyết định phía máy chủ.

Hãy kiểm tra đường hầm, và biết điều openconnect sẽ không sửa

Hãy xem đường hầm thực sự đã áp dụng gì thay vì tin vào thông báo thành công. Cổng ra gửi định tuyến và cấu hình dưới dạng XML và ứng dụng áp dụng chúng, nên một tuyến bị thiếu là vấn đề cấu hình hoặc lựa chọn chứ không phải lỗi ứng dụng:

ip -4 addr show
ip route
resolvectl status

MTU đáng được xem riêng. Cấu hình của GlobalProtect luôn báo MTU bằng không, nên ứng dụng ước lượng một giá trị từ chi phí đóng gói. Những lần truyền lớn bị kẹt trong khi các yêu cầu nhỏ vẫn đi qua là triệu chứng kinh điển, và cách chữa là một MTU tường minh trên kết nối chứ không phải tắt việc dò đường.

IPv6 lại là câu chuyện riêng. PAN thêm nó trong GlobalProtect 4.0, và hỗ trợ của OpenConnect được mô tả là thử nghiệm từ phiên bản 9.0, nên đừng cho rằng họ địa chỉ này hành xử như IPv4 chỉ vì đường hầm đã lên. Và nếu cổng ra áp đặt một kiểm tra posture mà ứng dụng mã nguồn mở không thể đáp ứng, hãy chạy ứng dụng của nhà cung cấp trên một bản LTS được hỗ trợ, trong máy ảo nếu máy trạm của bạn đã đi trước. Điều đó giữ nguyên máy tính để bàn và đặt phụ thuộc cũ vào bên trong một ranh giới mà bạn có thể dựng lại.