Linux에서의 Kerio VPN 클라이언트: 순서대로 하는 다섯 가지 점검

Linux에 Kerio VPN 클라이언트를 설치한 뒤 데스크톱 아이콘이 나타나지 않고 사설 네트워크에 닿을 수 없습니다. 이것은 설치가 깨진 것이 아니라 이 클라이언트의 정상적인 모습입니다. GFI의 Linux 안내는 명령줄 설정과 서비스 스크립트를 설명하며 GUI는 전혀 없습니다. 아래 점검을 순서대로 진행하십시오. 각 점검이 서로 다른 계층을 걷어내기 때문입니다. 첫 실패가 어디서 멈출지 알려 주며, 앞질러 가는 것은 대개 문제가 아니었던 패키지를 다시 빌드하는 일이 됩니다.

빌드가 기계와 맞는지 확인하십시오

먼저 dpkg 가 기계를 무엇으로 보는지, 패키지가 무엇을 위해 빌드되었는지부터 시작하십시오. 일반적인 64비트 시스템에서 dpkg --print-architecture 는 amd64 를 출력하고, 공급업체 페이지는 일반 Debian 패키지 옆에 amd64 패키지를 나열합니다. 실제로 설치한 파일 이름의 릴리스 문자열을 읽으십시오. 둘이 일치한다고 가정하지 마십시오.

2013년에 i386용으로 빌드된 아카이브는 --force-architecture 를 넘겼다는 이유만으로 64비트가 되지 않습니다. 강제로 설치하면 외래 바이너리가 들어가고, 여전히 시작되는 실행기의 뒤에 의존성 실패가 숨고, 데몬이 잘못된 라이브러리를 적재할 수 있습니다. 쓰고 있는 릴리스가 32비트뿐이라면 32비트 환경에서 실행하거나 게이트웨이 소유자에게 최신 빌드를 요청하십시오.

의존성 줄도 확인하십시오. dpkg -s kerio-control-vpnclient | grep -i depends 패키지가 무엇을 기대하는지 보여 주며, 충족되지 않은 버전 고정이나 빠진 런타임 라이브러리가 여기에서 드러납니다. 클라이언트 로그가 아닙니다.

패키지 마법사로 설정하십시오

설계상 클라이언트는 앱 서랍에 항목이 없으므로 아이콘이 없는 것은 설정 성공 여부를 말해 주지 않습니다. 마법사를 다시 열려면 sudo dpkg-reconfigure kerio-control-vpnclient 를 실행하고 질문에 답하십시오: VPN 엔드포인트, 계정 정보, 서버 인증서의 지문입니다.

지문 질문을 잘못된 서버가 이길 수 있는 유일한 지점으로 보십시오. 값을 게이트웨이를 운영하는 관리자가 준 서버 정보와 비교하고, 엔드포인트가 제시하는 것과 비교하지 마십시오. 검증할 수 없는 지문을 받아들이면 이 목록의 나머지는 장식이 됩니다. 핀이 저장된 뒤에는 악의적인 서버가 진짜와 똑같아 보이기 때문입니다. 값을 다른 경로로 확인할 수 없다면, 터널이 다른 방식으로 올라오더라도 멈추고 물으십시오.

마법사를 다시 실행하면 설정이 바뀌고 클라이언트가 재시작될 수 있으므로, 작업 중인 세션이 그 VPN에 의존한다면 기계로 가는 두 번째 경로를 확보하십시오. 암호는 셸 기록에 남는 명령에 넣지 말고 일반 프롬프트에서 입력하십시오.

마법사가 쓰는 파일을 아십시오

설정은 /etc/kerio-kvc.conf 에 있고 계정과 고정된 지문을 모두 담습니다. 비밀 자료로 다루십시오. sudo stat -c '%a %U %G' /etc/kerio-kvc.conf 은(는) 그것을 모든 사람이 읽을 수 있는 형태로 보여 주어서는 안 됩니다.

허가된 수동 편집 뒤에는 네트워크 스택을 재시작하는 대신 파일을 소유한 데몬을 다시 읽으십시오: sudo /etc/init.d/kerio-kvc reload. 다시 읽기는 설정을 새로 읽고 현재 세션을 끊으므로, 살아 있는 연결에서는 무해한 동작이 아닙니다.

무엇이든 바꾸기 전에 이전 파일을 복사하십시오. 편집 뒤 인증이 실패하면 마지막 정상 사본을 되돌리는 데 몇 초가 걸리고 편집을 네트워크와 분리할 수 있습니다. 둘 중 어느 쪽이 움직였는지 알 가장 싼 방법입니다.

살아 있는 세션과 부팅 동작을 분리하십시오

서비스 스크립트는 현재 연결을 제어합니다: sudo /etc/init.d/kerio-kvc stop 는 지금 터널을 끝내고 start 는 그것을 되돌립니다. 어느 명령도 다음 부팅에서 무슨 일이 일어날지 정하지 않으며, 그 차이는 원격으로 관리하는 기계에서 중요합니다.

링크를 제거하거나 무엇인가를 가리기 전에 시작의 주인이 누구인지 확인하십시오. 패키지가 자체 init 스크립트를 설치하거나 unit을 생성하거나 둘 다 할 수 있으며, 잘못된 이름을 비활성화하면 재부팅 뒤 클라이언트가 되살아납니다. systemctl status kerio-kvc 를 패키지 문서가 쓰는 이름과 대조한 다음, 부팅 과정이 실제로 읽는 경로를 비활성화하십시오.

설정이 비슷해 보인다고 OpenVPN unit으로 바꾸지 마십시오. 이 클라이언트는 Kerio 게이트웨이와 자체 프로토콜로 대화하므로 같은 파일을 가리키는 다른 데몬은 인증되지 않습니다, 그리고 추가 실패는 증거를 읽기 어렵게 만듭니다. GFI의 Linux 클라이언트는 한 번에 VPN 연결 하나만 유지합니다. 그 한도는 클라이언트에 적용되며 게이트웨이의 사용자 수용력에는 적용되지 않습니다.

로그를 읽고 나서 리소스를 검증하십시오

세 개의 파일이 /var/log/kerio-kvc 에 데몬의 이야기를 전합니다: init.log 는 수명 주기 사건, error.log 는 치명적 실패, debug.log 는 세부 정보입니다. 질문에 답하는 가장 작은 발췌를 읽고, 어디에 붙이기 전에 엔드포인트와 사용자 이름을 지우십시오. init.log 에서 마법사를 실행한 시점 언저리에 공백이 있으면 데몬이 한 번도 재시작되지 않았다는 뜻입니다.

유효한 패키지, 실행 중인 데몬, 도달 가능한 리소스는 세 가지 별개의 결과이며, 셋이 모두 성립할 때만 목록이 끝납니다. 승인된 변경 뒤에는 게이트웨이 뒤에만 존재하는 호스트를 요청하고, 그다음 그 위에서 일반 서비스를 여십시오. 터널이 올라와 있는데 리소스에 닿지 않는다면 남은 결함은 게이트웨이 경로나 방화벽 규칙에 있으며, 방금 다시 설정한 클라이언트에 있지 않습니다.

끝낸 상태를 기록하십시오: 패키지 릴리스, 아키텍처, 지문을 다른 경로로 검증했는지, 어떤 다시 읽기나 재시작을 했는지. 그 메모가 다음 사람의 첫 점검을 싸게 만듭니다.