Linux의 Check Point VPN: SNX는 내려받아 설치하는 것이 아니다

Check Point의 Linux 클라이언트를 찾아보면 설치 프로그램이 있는 내려받기 페이지가 없습니다. 그 부재는 패키징의 구멍이 아닙니다. Check Point의 Linux 원격 접속 클라이언트는 SSL Network Extender, 즉 SNX이며, 브라우저에서 인증한 뒤 게이트웨이가 그것을 건넵니다. 이것이 자리 잡으면 나머지 혼란도 이해가 됩니다. 이 주제를 다룬 거의 모든 글이 몇 년 전 것인 이유도 그 때문입니다.

속설: 내려받아 설치하는 클라이언트가 있다

그 기대는 다른 모든 공급업체에서 옵니다. OpenVPN, WireGuard 그리고 대부분의 상용 클라이언트는 패키지나 저장소를 공개하며, 설치 여부는 혼자 내리는 로컬 결정입니다. Check Point는 Linux에서 그렇게 동작하지 않습니다. 현재 게이트웨이 버전의 공식 내려받기에는 별도 설치 프로그램이 없어서, 그것을 찾으면 오래된 포럼 글타래와 제삼자 미러만 나옵니다.

그 미러는 쓸모없는 정도가 아니라 해롭습니다. 빌드는 그것을 제공하는 게이트웨이와 맞아야 하기 때문입니다.

SNX의 실체와 출처

SNX는 바이너리 이름이 snx인 명령줄 클라이언트이며, 브라우저에서 게이트웨이를 상대로 시작한 세션을 통해 설치됩니다. 과거에는 Java 애플릿이 안내 창에 동의한 뒤 내려받아 설치했습니다. 방식은 해마다 바뀌었지만 출처는 그대로입니다. 게이트웨이는 자기 자신과 맞는 빌드를 제공하므로 클라이언트와 게이트웨이 버전이 함께 움직이고, 오래된 패키지에서 복사한 클라이언트는 게이트웨이가 아직 그것과 대화하는 동안에만 동작합니다.

이는 클라이언트 쪽 작업이 의미를 갖기 전에 게이트웨이가 준비되어 있어야 한다는 뜻이기도 합니다. Mobile Access Software Blade의 라이선스와 설정이 필요하며, 그것이 없으면 설치할 포털이 없습니다. 포털을 제공하지 않는 게이트웨이를 상대로는 클라이언트 쪽의 어떤 노력도 세션을 만들지 못합니다.

자기 사용자 이름으로 클라이언트를 게이트웨이로 향하게 하고, 무엇을 보고하는지 읽습니다:

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

제약은 설치 프로그램이 아니라 배포판 지원이다

SNX에 대해 공급업체가 지원한다고 밝힌 배포판 목록은 짧고 오래되었습니다. 공개된 글에서는 Ubuntu 17.04 근처에서 멈추고, 같은 시기의 openSUSE, Fedora, RHEL 몇 개 버전이 나란히 있으며, 지금도 Ubuntu 12.10이 올라 있습니다. 이것은 목록이 어떻게 늙는지를 말해 줄 뿐, 당신의 기계에 무엇이 필요한지는 아닙니다. 현재 배포판은 아예 없습니다.

동작하는 터널을 기대하기 전에 라이브러리 불일치를 각오하십시오. 흔한 세 가지는 64비트 시스템에서 빠진 32비트 라이브러리, 바이너리가 한 번도 링크된 적 없는 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 또는 NetworkManager의 L2TP 플러그인으로 동작합니다. 그것은 게이트웨이 설정이지 클라이언트 요령이 아닙니다. 게이트웨이가 Mobile Access 포털만 게시한다면IPsec 클라이언트가 협상할 상대가 없습니다. 로그에는 인증 실패 대신 시간 초과가 찍힙니다. 다른 무엇을 설치하기 전에 어떤 원격 접속 블레이드가 켜져 있는지 물어보십시오.

여기서 모든 제약은 게이트웨이 쪽에 있습니다. 블레이드, 라이선스, 클라이언트 빌드, 경로 프로필입니다. CLI는 수년째 동작합니다. 깨지는 것은 Linux 지원이 곧 자신이 소유하고 통제하는 패키지라는 가정입니다.