최신 Ubuntu에서 GlobalProtect Linux 클라이언트가 실패하는 이유

합리적인 추측은 GlobalProtect 포털에서 받은 .deb이 깨졌거나 벤더가 잘못된 빌드를 배포했다는 것이다. 대개 그렇지 않다. 벤더의 Linux UI는 여전히 Qt5 WebKit에 링크되어 있고 최신 Ubuntu 릴리스는 그것을 더 이상 싣지 않으므로, 패키지는 배포판이 일부러 제거한 라이브러리를 요구하고 있다. 이것은 손상된 다운로드가 아니라 패키징의 불일치이고, 그 차이가 오후를 패키지 강제 설치에 쓸지 십 분을 다른 클라이언트 선택에 쓸지를 결정한다.

deb 패키지는 깨지지 않았다

배포판이 더 이상 싣지 않는 의존성은 라이브러리가 은퇴한 정상적인 결과다. Qt5 WebKit은 이후 Ubuntu 아카이브와 Debian에서 빠졌고, 이유는 수요 부족이 아니라 보안 유지보수였다. 그런 일이 생기면 아직 그것에 링크된 모든 패키지는 아무리 잘 빌드되었어도 설치할 수 없게 된다.

같은 버그로 보고되는 두 실패는 사실 같지 않다. 라이브러리가 없는 릴리스에서는 설치 프로그램이 충족되지 않은 의존성에서 멈춘다. 클라이언트가 설치된 뒤 로그인에서 실패하는 릴리스에서는 내장 브라우저 구성 요소 안의 TLS나 SAML 핸드셰이크 문제를 보는 것이다. 앞은 패키징이고 뒤는 실행 시간이며, 둘 다 옛 라이브러리를 현대적인 데스크톱에 복사해서 고쳐지지 않는다.

의존성을 강제하지 말고 확인하라

패키지를 분명히 설치해 도구가 요약 대신 해결되지 않은 의존성의 이름을 대게 하고, 그다음 당신의 릴리스에 후보가 아예 있는지 물어라. „여기서는 구할 수 없다”와 „이 미러에서 일시적으로 빠졌다”는 전혀 다른 결정으로 이어진다:

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

만약 apt-cache policy가 후보를 보고하지 않으면, 설치를 시도하는 것을 멈추고 대안 선택으로 넘어가라. 흥미로운 것은 빠진 패키지 이름이 아니라, 벤더의 의존성 그래프가 사용자가 쓰는 배포판들과 함께 움직이지 않았다는 사실이다.

옛 패키지를 강제하면 데스크톱에 무슨 일이 생기는가

떠도는 우회책은 더 오래된 릴리스에서 라이브러리를 끌어오는 것이다. 현재 Ubuntu에서는 이것이 Qt5 마이너 버전 충돌로 이어지고, 옛 패키지가 libqt5core5t64를 거꾸로 끌어당기고, 그러면 설치된 KDE와 PyQt 패키지가 강등된 라이브러리가 더는 제공하지 않는 ABI 버전을 요구하기 시작한다. 결과는 무관한 응용 프로그램을 깨뜨리는 부분 업그레이드이고, 그것은 시작했던 오후보다 훨씬 나쁘다.

그 결과는 예상된 것이지 불운이 아니다. Qt의 마이너 버전에 대한 ABI 기대는 엄격하고, 배포판은 일관된 한 벌을 공급한다. 다른 릴리스의 라이브러리를 하나 섞는 것은 표적 수정이 아니라 통제가 덜 되는 두 번째 업그레이드다.

같은 조언이 실패의 실행 시간 쪽에도 적용된다. 옛 클라이언트의 핸드셰이크가 통과하도록 OpenSSL의 시스템 전반 보안 수준을 낮추는 것은 응용 프로그램 하나를 고치기 위해 기계의 모든 TLS 연결을 바꾸는 일이며, 다른 것이 고장 났을 때 필요할 패키지 관리자도 포함된다.

openconnect는 그 프로토콜을 말한다

OpenConnect는 GlobalProtect의 프로토콜을 직접 구현하며, 프로토콜 노트는 호출 방식과 두 서버 인터페이스 사이의 분담을 함께 설명한다. 포털은 설정과 게이트웨이 목록을 나눠 주고, 게이트웨이가 터널을 끝낸다:

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

포털이 필요한 게이트웨이를 빼놓는다면, --usergroup=gateway 또는 /gateway로 끝나는 URL은 포털 단계를 건너뛴다. 여러 게이트웨이가 제시되면, --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 릴리스에서, 직장 기계가 이미 앞서 갔다면 가상 머신 안에서 돌려라. 그것이 데스크톱을 온전히 두고 오래된 의존성을 다시 지을 수 있는 경계 안에 놓는다.