하나의 앱을 VPN으로만 강제할 수 있는 macOS 도구는 무엇인가?

요구사항 문서의 한 줄, “이 앱은 VPN을 쓸 수 있고 그 외에는 아무것도 쓸 수 없다”는 어떤 단일 스위치도 제공하지 않는 두 메커니즘을 조용히 요구한다. 트래픽에는 의도한 터널을 통과하는 경로가 필요하고, 곧바로 빠져나갈 트래픽은 거부되어야 한다. 둘 중 하나는 잘하고 다른 하나는 전혀 못하는 도구가 흔하기 때문에, 무언가를 차단할 수 있는지만 묻는 비교는 질문의 절반에 자신 있게 답한다. 먼저 경계를 적고, 그다음 그 두 절반을 모두 덮는 구성 요소를 고르라.

한 문장 안에 숨은 두 가지 요구사항

유도는 연결을 터널이나 프록시에 넣는 부분이다. 거부는 같은 연결이 다른 어떤 경로로도 나가지 못하게 막는 부분이다. 서로 다른 구성 요소가 이를 구현하고, 서로 다른 방식으로 실패하며, 한 제품이 한쪽에서는 뛰어나면서 다른 쪽에 대해서는 아무 말도 하지 않을 수 있다:

표를 순위가 아니라 점검 목록으로 읽으라. 어떤 행도 가운데 두 열을 모두 채우지 못하며, 그 둘을 덮는 행은 협력하는 두 구성 요소다. 하나는 경로를, 다른 하나는 거부를 소유한다. 정체성 열이 다른 이유로 중요한 것은, 앱을 지목할 수 없는 규칙은 그 앱에 대한 규칙을 강제할 수 없기 때문이다. 무엇을 배포하든 세 가지 모두에 답해야 하며, 그렇지 않으면 요구사항 문서의 경계는 기계 위의 경계가 아니다.

유도만으로는 출구가 남는다

애플리케이션 프록시 설정은 거부 없는 유도의 가장 분명한 예다. 시스템 프록시를 존중하는 앱의 요청은 유도할 수 있지만 그 밖에는 아무것도 덮지 않는다. 도우미 프로세스, 업데이터, 백그라운드 서비스, 다른 프로토콜은 그 설정을 한 번도 읽지 않고 자기 경로로 갈 수 있다. 따라서 한 패널에서 SOCKS 엔드포인트를 고르는 것이 그 애플리케이션에 대한 직접 출구 금지 정책을 만들지는 않는다. 요구사항이 앱 전체에 관한 것이라면, 규칙이 실제로 어떤 구성 요소를 식별하는지 물어야 한다.

앱별 VPN 프로필은 어떤 앱이 터널에 들어갈지를 플랫폼이 결정하기 때문에 프록시보다 잘 유도한다 각 앱이 스스로 결정하는 대신. 그래도 아무것도 거부하지 않는다. 프로필은 경로를 제공하고, 그것에 맞지 않는 트래픽은 평소 경로를 택한다. 바로 그 틈이 두 번째 구성 요소가 제자리를 얻는 지점이며, 하나의 스위치처럼 보이는 제품이 보통 둘인 이유다.

거부만으로는 앱이 망가진다

Apple의 콘텐츠 필터 문서는 트래픽이 네트워크 스택을 지날 때 허용-또는-차단 판정을 설명한다. 그 판정은 터널도 프록시 연결도 아니다. 무언가가 계속될 수 있는지를 결정할 뿐 어디로 가는지는 결정하지 않는다. 필터 단독은 거부를 완벽하게 강제하고 애플리케이션을 쓸 수 없게 만든다. 로그는 깨끗하고 설명은 없다. 필터 판정은 연결을 멈출 수 있지만 터널을 결코 제공하지 않으므로, 유도와 짝지어야 하는 것은 선택적 추가가 아니라 설계 결정이다.

로컬에서 관리하는 PF 규칙 집합은 그 스펙트럼의 반대쪽 끝에 있다. 관리자가 소유한 기계에서 정당한 지원 결정이며, 배포 가능한 제품의 토대가 자동으로 되는 것은 아니다. 규칙 집합을 소유한 사람은 다른 방화벽 사용자와의 상호작용, 업그레이드 경로, 규칙이 틀렸을 때의 복구까지 소유하기 때문이다. 제품에 PF를 더한다고 그 소유권 질문이 사라지지 않으며, 오히려 정의된다.

배포가 그 규칙이 내일도 존재할지를 결정한다

Apple 플랫폼에서 Network Extension이 배포되는 방식은 공급자 유형, 패키징, 눈앞의 운영체제 버전에 달려 있다. macOS의 앱 확장은 사용자 컨텍스트에서 실행되고 그 사용자가 로그아웃하면 끝난다. 반면 시스템 확장은 세션에 의존하지 않는 전역 컨텍스트를 가진다. 보호가 로그아웃을 넘어 유지되어야 한다면 그 차이가 각주가 아니라 설계 전부다. 동작을 약속하기 전에 배포 경로를 확인하라. 같은 코드라도 어떤 확장 유형을 내보내는지에 따라 다르게 도착한다.

소스의 가용성은 적용과 별개의 문제다. 저장소를 읽으면 무엇이 어떻게 구현되었는지는 알 수 있지만, 설치된 바이너리가 이 기계에서 무엇을 해도 되는지는 알 수 없다. 서명, 설치, 권한 부여는 여전히 적용되며, 낡은 커널 확장이나 라이브러리 주입 요령을 전제로 한 지침은 한때 아무리 잘 작동했더라도 다른 플랫폼과 다른 위험 태도를 설명한다.

앱을 지목하는 승인 사례

앱이 스스로 수행하는 동작 하나를 골라, 도달해야 할 주소와 그 주소가 IPv4인지 IPv6인지 기록하고, 승인된 터널 없는 상태에서 같은 동작을 반복하라. 두 번째 실행은 조용한 직접 재시도가 아니라 선언된 거부를 낳아야 한다. 그것이 사람들이 명시하지 않고 남기는 절반이며, 거부가 존재한다는 것을 증명하는 유일한 절반이다. 먼저 터널이 있는 상태에서 실행해, 두 결과의 차이가 사라진 터널에서만 비롯되게 하라.

그다음 요구사항이 지목하는 전환을 따라가라. 앱 재시작, 도우미 프로세스 작동, 터널 재연결, 기계의 네트워크 변경, 그리고 해당되는 경우 로그아웃이나 재부팅이다. 브라우저의 공용 IP 페이지는 다른 애플리케이션의 소켓 시험이 아니므로 이것을 대신할 수 없다. 지원되는 배포가 앱의 실제 동작을 덮지 못하는 경우, 명시적 게이트웨이를 갖고 대체 출구가 없는 승인된 격리 환경은 자체 관리 비용이 드는 억제 결정이지 체크박스의 대체물이 아니다.

마지막으로 네 항목을 적어라. 앱이 어떤 구성 요소로 이루어지는지, 유도를 누가 소유하는지, 거부를 누가 소유하는지, 그리고 규칙이 여전히 유효해야 하는 상태다. 공개 저장소는 선택 기준 하나가 될 수 있지만 그 네 가지 중 하나는 아니며, 그 항목들이 특정 도구가 네트워크 요구사항을 충족하는지를 결정한다.