Linux에서의 SNX: 32비트 라이브러리와 스스로 초기화되는 리졸버

Check Point의 SSL Network Extender는 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을 마운트하고 광범위한 권한을 부여해야 하며, 이는 호스트 네트워크 관리의 대부분을 컨테이너에 넘깁니다.

정말 샌드박스가 필요할 때는 가상 머신이 더 깨끗한 경계입니다: 클라이언트는 변경해도 되는 커널을 받고, 호스트는 라우팅 테이블을 유지합니다. 부여한 것을 후회할 권한에 오후를 쓰기 전에 그것을 선택하세요.