OpenVPN 엔진일까 Tunnelblick일까: Mac VPN 세션의 주인은 누구인가?

Homebrew는 OpenVPN 프로그램을 설치하고, Tunnelblick은 하나 이상의 엔진을 실행하는 관리자를 설치한다. 이들은 서로 다른 계층이며, 유용한 질문은 터미널 사용을 좋아하는지가 아니다. 구성, DNS 변경, 자격 증명 요청, 세션 종료 시 정리를 누가 소유하는지다. 이 계층들에 하나의 소유자가 있는 것이 구성을 예측 가능하게 만든다.

아래 다섯 가지 점검을 순서대로 하라. 소유자가 둘인 첫 점검이 사람들이 OpenVPN 자체를 탓하는 이상한 반쯤 연결된 상태를 만든다. 각 점검은 그것을 판정하는 증거를 밝힌다.

점검 하나: 어떤 OpenVPN 바이너리가 실제로 실행되는가

연결된 상태에서 pgrep -fl openvpn을 실행하고 전체 명령줄을 읽어라. 첫 번째 경로가 실제로 실행 중인 엔진이다. Apple Silicon에서는 Homebrew 설치가 보통 /opt/homebrew 아래에 있고, Intel Mac은 /usr/local을 사용하며, Tunnelblick은 자체 애플리케이션 번들 안에서 엔진을 실행한다.

Tunnelblick은 엔진을 번들하고 구성이 그중 하나를 고르게 한다. Homebrew 공식을 업데이트하면 독립 바이너리가 바뀌지, Tunnelblick 프로필이 시작하는 엔진이 바뀌는 것은 아니다. 동작 차이를 설명하려고 버전을 비교한다면 패키지 관리자의 엔진이 아니라 프로세스 목록의 엔진을 비교하라. 버전 문자열만으로는 그 엔진이 어떤 프로필을 로드했는지 알 수 없다.

복사한 프로필은 서로 다른 파일을 읽으면서도 두 엔진을 똑같이 보이게 할 수 있다. 명령줄의 프로필 경로는 실행 중인 프로세스가 어떤 구성을 로드했는지 알려주며, 편집기에서 연 프로필은 증거가 아니다. 동작을 비교하기 전에 그 경로를 비교하라.

점검 둘: DNS와 경로를 누가 바꾸는가

엔진은 OpenVPN 자체의 up 및 down 지시문을 실행할 수 있지만, 관리자가 같은 수명 주기를 소유할 수 있다. Tunnelblick의 이름 서버 설정은 표준 연결 및 해제 스크립트를 제어하며, 그 통합이 켜져 있으면 프로필의 경쟁 지시문이 무시될 수 있다.

DNS는 동작하는 터널이 가장 자주 고장 나 보이는 지점이기 때문이다. 연결된 상태에서 scutil --dns를 확인하고, 어느 리졸버가 첫 번째인지 기록하며, 연결 해제 후 돌아오는지 확인하라. 프로필이 스스로 DNS를 설정하려는데 관리자도 이를 관리한다면 둘 중 하나는 진다.

첫 연결 전에 어느 계층이 DNS를 소유하는지 정하고, 둘 다 남기지 말고 지는 지시문을 제거하라. 경로 변경도 같은 규칙을 따른다: 소유자는 하나, 구성에 보이고, 복원 경로가 문서화되어야 한다.

점검 셋: 자격 증명은 어디서 오는가

대화형 요청과 무인 프로세스는 요구 사항이 다르다. 한 애플리케이션이 저장한 자격 증명이 다른 프로세스에 자동으로 제공되지 않으며, 관리자에게 한정된 키체인 항목은 셸에서 시작한 독립 엔진에 보이지 않을 수 있다.

프로필의 자격 증명 출처를 나열하라: 클라이언트 인증서와 키, 사용자 이름과 암호 요청, 또는 외부 도우미가 제공하는 토큰이다. 그다음 연결이 재부팅을 견뎌야 한다면 선택한 소유자가 사람 없이 그 출처에 닿을 수 있는지 확인하라.

점검 넷: 프로세스를 누가 시작하고 감독하고 멈추는가

독립 배포가 계속 떠 있어야 한다면 감독자가 필요하다. Launchd는 로그인 시 또는 요청 시 엔진을 시작하고, 충돌 후 다시 시작하며, 깔끔하게 멈출 수 있지만 누군가 그 작업을 작성하고 소유해야 한다. 터미널에서 명령을 실행하는 것은 시험에는 맞고 창을 닫는 사용자에게는 맞지 않는다.

Tunnelblick이 소유자로 남는다면 두 번째 엔진을 시작하지 말고 지원되는 제어를 사용하라. Homebrew 바이너리는 복사한 프로필을 받으면 기존 Tunnelblick 세션에 명령하는 대신 자체 구성과 통합 컨텍스트로 독립 연결을 연다.

어떤 소유자를 고르든 잠자기, 네트워크 변경, 로그아웃 시 무슨 일이 일어나는지 정의하라. 관리자는 보통 그런 이벤트를 처리하지만 맨 프로세스는 보통 처리하지 않으며, 그 결과 남는 오래된 경로나 리졸버는 서버 장애로 잘못 읽히기 쉽다.

점검 다섯: 인계를 어떻게 검증하는가

이전 소유자를 비활성화한 상태에서 새 소유자를 시험하고, 유지할 계획이라면 이전 소유자를 다시 시험하라. 한 워크플로에서는 응답하고 다른 워크플로에서는 응답하지 않는 사설 리소스는 빠진 통합에 대한 증거이며 서버에 대한 증거가 아니다.

독립 엔진으로 인계하려면 프로필 경로, 바이너리 경로, 감독자, DNS 소유자, 자격 증명 출처를 기록하라. 그다음 그 순서대로 사설 리소스, 공용 인터넷 경로, 깔끔한 연결 해제를 검증하라. 연결 해제 후 DNS나 경로가 남는다면 새 소유자는 끝난 것이 아니다.

Tunnelblick으로 인계하려면 구성의 엔진을 고르고, 의도한 DNS 통합을 켜고, 그것과 충돌하는 프로필 지시문을 제거하라. 그다음 같은 세 가지 점검을 반복하라. 동작하지만 리졸버를 바뀐 채로 두는 연결은 터널이 올라왔더라도 실패한 인계다.

패키징은 서버 호환성을 결정하지 않는다. 서비스 자체의 클라이언트 요구 사항을 확인하고, 그 관리를 직접 제공할 생각일 때만 엔진 단독을 골라라.