macOS에서의 OpenConnect: 패키지, 릴리스 아카이브, git 클론

Mac에서 OpenConnect 클라이언트를 얻는 길은 세 가지이며, 디스크에 남기는 것이 각각 다릅니다. Homebrew 포뮬라는 컴파일된 바이너리와 경로 및 DNS를 설정하는 네트워크 스크립트를 설치합니다. 릴리스 아카이브는 생성된 빌드 시스템이 포함된 소스 코드를 줍니다. git 체크아웃은 그것이 없는 소스 코드를 줍니다. 잘못된 쪽을 고르면 튜토리얼을 시작한 지 몇 분 만에 configure가 없다는 상황을 만나게 됩니다.

같은 이름 아래의 서로 다른 두 기계

패키지 경로는 명령 하나이며, 개발이 아니라 연결이 일인 사람에게 맞는 기본값입니다.

brew install openconnect

무엇을 설치하는지가 명령보다 중요합니다. 클라이언트 바이너리를 얻고, 인터페이스와 경로, 리졸버를 프로그래밍하려고 클라이언트가 호출하는 vpnc-script도 얻습니다. 둘은 한 쌍으로 동작합니다. 바이너리가 TLS 세션을 끝내고 생긴 인터페이스를 스크립트에 넘기며, 스크립트는 이 운영체제가 네트워크를 어떻게 바꾸길 원하는지 아는 부분입니다.

이 분리가 혼란스러운 보고의 한 부류 전체를 설명합니다. 연결하고 성공을 보고한 뒤 트래픽을 잘못된 경로로 보내는 클라이언트는 보통 터널이 아니라 스크립트 문제이며, 포뮬라를 다시 설치하면 고쳐지는 것은 스크립트도 함께 다시 설치되기 때문일 뿐입니다. 포뮬라의 현재 macOS 및 CPU 아키텍처 지원을 그것을 전제로 계획하기 전에 확인하세요. 셸을 완벽히 실행하는 Mac이라도 그것을 위해 빌드된 최신 패키지가 없을 수 있습니다.

소스 경로가 실제로 하는 일

릴리스 아카이브에는 생성된 빌드 시스템이 함께 오므로 익숙한 ./configure가 처음부터 있습니다. git 체크아웃에는 없습니다. 생성된 파일은 빌드 산출물이지 프로젝트가 보관하는 것이 아니기 때문입니다. 체크아웃 안내에 ./autogen.sh가 나오고 릴리스 아카이브에는 나오지 않는 이유가 바로 이것입니다.

./autogen.sh
./configure
make
make install

각 줄은 특정한 일을 하며, 어느 줄이 실패했는지 알면 추측이 크게 줄어듭니다. autogen 단계는 autotools를 실행해 configure를 만듭니다. configure 단계는 클라이언트에 필요한 컴파일러와 라이브러리, 헤더를 검사한 뒤 찾은 것을 반영한 makefile을 씁니다. make 단계는 컴파일합니다. install 단계는 결과를 경로 어딘가로 복사합니다.

바로 그 마지막 줄에서 조언이 자주 어긋납니다. 설치는 빌드가 성공했다는 증거가 아니며, 아무 다운로드 폴더에서 높은 권한으로 실행하는 것은 나중에 기억나지 않을 파일을 흩뿌리는 좋은 방법입니다. 라이브러리가 없어 configure가 실패하면 쓸모 있는 출력은 그것이 처음 찍은 오류이지 로그의 마지막 스무 줄이 아닙니다.

세션과 네트워크 구성은 별개

이 구분이 연결이 실제로 트래픽을 나르는지를 결정합니다. TLS 세션을 세우면 클라이언트 쪽에 인터페이스가 생깁니다. 경로와 주소, DNS 리졸버를 적용하는 것은 네트워크 스크립트를 통해 하는 두 번째 단계이며, 스크립트 없이 바이너리를 만든 빌드는 절반의 클라이언트입니다.

같은 분리가 동일한 클라이언트를 가진 두 기계가 다르게 동작하는 이유를 설명합니다. 스크립트가 시스템의 네트워크 구성을 참조하고, 그 구성에는 경로를 주장한 다른 모든 것이 포함됩니다. 분할 터널이 트래픽을 예상 밖의 곳으로 보낼 때 터널은 제 일을 하고 있으며, 살펴야 할 것은 라우팅 결정입니다.

그러므로 디버깅할 때는 어느 계층이 실패했는지 물으세요. 결코 맺어지지 않는 세션은 프로토콜, 인증서, 자격 증명입니다. 맺어지고도 아무것도 전달하지 않는 세션은 인터페이스와 스크립트입니다. 한 네트워크에서는 되고 다른 네트워크에서는 안 되는 설치된 클라이언트는 도달성이며, 아무리 다시 빌드해도 바뀌지 않습니다.

어떤 바이너리를 실행 중인지 아세요

손으로 설치한 빌드와 패키지된 바이너리는 평화롭게 공존할 수 있고, 어느 쪽이 실행되는지는 의도가 아니라 경로에 달려 있습니다. 누군가에게 버전 번호를 알리기 전에 확인하세요.

which -a openconnect
openconnect --version
brew list --versions openconnect

첫 명령은 셸이 보는 모든 복사본을 시도할 순서대로 나열합니다. 두 번째는 어느 것이 응답했는지 알려 줍니다. 그것이 기대와 어긋나면 옛 실험의 빌드를 실행 중이며, 어떤 구성 변경도 그것을 옮기지 못합니다.

클라이언트 설치가 게이트웨이 승인은 아닙니다

동작하는 바이너리가 배포를 호환되게 만들지는 않습니다. 게이트웨이의 프로토콜과 인증 흐름, 관리 기기 요구 사항을 그것을 소유한 사람들과 확인하세요. 그것은 빌드가 제공할 수 없는 정책과 응용 계층의 사실입니다.

프로젝트의 빌드 지침은 autotools 순서와 네트워크 스크립트 요구 사항을 더 자세히 다루며, 여러분의 macOS 버전보다 오래된 블로그 글 대신 이것을 따라야 합니다. 목표가 그저 연결이라면 패키지를 택하고 스크립트를 유지하며 컴파일러는 배제하세요.