Mac PF VPN 잠금: 배포 가능한 기능이 아닌 사이트 정책

Mac에서 작동하므로 사용자에게 넘길 수 있는 것처럼 보입니다. 그 가정이 가장 먼저 버려야 할 것입니다. Apple의 TN3165는 Packet Filter가 일반적으로 배포되는 제품을 위한 지원 API가 아니라고 분명히 밝히며, 권한이 있고 통제된 사이트 관리를 합당한 사례로 제시합니다. 따라서 PF로 만든 VPN 잠금은 소유자가 있는 로컬 운영 정책이며, 앱 안에 넣어 배포할 수 있는 기능이 아닙니다.

PF는 패키징 표면이 아니다

이 구분은 학문적이지 않습니다. PF에 의존하는 배포 제품은 Apple이 가하는 모든 변경, 규칙을 쓰는 다른 도구와의 모든 충돌을 물려받으며, 이 구성이 계속 작동한다는 지원 약속도 받지 못합니다. 자체 머신을 관리하는 사이트는 관계가 다릅니다. 의존성을 문서화하고, 각 OS 릴리스에 대해 테스트하고, 유지 관리를 감수할 수 있습니다.

일부 설치 조언은 이름 붙일 가치가 있는 선을 넘습니다. 하나의 앵커를 로드하기 위해 시스템 규칙 집합 전체를 덮어쓰거나, Apple의 시스템 시작 구성을 편집하거나, System Integrity Protection을 비활성화하는 것은 재사용 가능한 레시피에 허용되는 요구 사항이 아닙니다. 공개된 안내서가 그중 하나라도 필요로 한다면, 그것은 실험실을 설명하는 것이지 배포 가능한 정책이 아닙니다.

구문보다 먼저 송출 의도를 쓰라

키워드를 하나 고르기 전에 무엇이 허용되는지 결정하십시오. 보통 세 가지 경로가 있어야 합니다. VPN 클라이언트 자체의 서버로의 전송, 터널 내부의 보호된 애플리케이션 트래픽, 그리고 설정이나 로컬 서비스가 정말로 직접 경로를 필요로 하는 모든 것.

제안된 모든 예외에 목적지, 전송, 소유자를 부여하십시오. 한 엔드포인트로 모든 포트를 허용하면 터널이 사용하는 단 하나의 전송보다 훨씬 많은 것을 허용하며, 추가 노출은 누구도 그것이 있어야 한다고 결정하지 않은 채 생깁니다. 공용 리졸버를 허용하는 것은 더 친근한 옷을 입은 같은 함정입니다. 터널이 내려가 있는 동안에도 직접 DNS 경로를 만들므로 이름 조회는 여전히 새어 나갑니다.

예외에 유용한 테스트는 그것을 요구한 사람과 그것이 막는 실패를 이름 붙일 수 있는지입니다. 두 답이 모두 없다면, 그 규칙은 아마도 그렇지 않으면 보이지 않게 남을 설정 오류에 대한 우회로입니다.

utun 번호는 신원이 아니다

MacOS는 터널 인터페이스를 utun 장치로 만듭니다. 그리고 VPN에 할당된 번호는 안정적이지 않습니다. 재부팅, 재연결, 다른 클라이언트의 존재에 따라 달라집니다. 추측한 여러 번호를 나열한 규칙은 정책이 아니며, 한 오후의 스냅샷입니다.

규칙은 의도한 공급자를 식별하는 무엇인가에 고정하십시오. 터널이 할당하는 주소 계획, 인터페이스를 소유한 프로세스, 또는 VPN 클라이언트 자체가 유지하는 구성입니다. 그런 다음 그 식별이 어떻게 작동하는지 기록하십시오. 일 년 뒤 규칙을 검토할 사람에게는 당신의 셸 기록이 없을 것입니다.

로드된 정책을 귀속 가능하게 만들라

앵커 이름은 규칙을 정리하지만, 실제 정책이 의도한 것임을 증명하지는 않습니다. 앵커 간 우선순위, 다른 소프트웨어가 로드한 규칙, 기존 상태가 모두 결과를 바꿀 수 있습니다. 그 머신에서 PF를 함께 소유한 사람과 실효 집합을 검토하고, 구성과 같은 위치에 소유권을 문서화하십시오. 서로 다른 가정으로 서로 다른 앵커를 편집하는 두 소유자가 잠금에 구멍이 생기는 평범한 경로입니다.

규칙 집합을 사이트의 지원되는 구성 경로에 두고, 버전을 관리하고, 어떤 macOS 릴리스가 테스트되었는지 기록하십시오. 손으로 적용하고 한 사람이 기억하는 변경은 파일 헤더가 무엇이라 하든 유지 관리되는 인프라가 아닙니다.

연결된 상태가 아니라 전환을 테스트하라

터널이 올라간 상태에서 찍은 스크린샷은 거의 아무것도 증명하지 않습니다. 대신 상태를 걸어 보십시오. 연결 전 시작, 작동하는 터널, 경고 없이 끊기는 터널, 의도적 연결 해제, Wi-Fi에서 핫스팟으로의 이동입니다. 각 상태에는 고유한 답이 있고, 흥미로운 것은 행복한 경로가 아니라 실패입니다.

각 상태에서 의도적으로 도달 가능한 것을 기록하십시오. IPv4와 IPv6를 따로 확인하고, 이름 해석을 테스트하고, 전환 전에 이미 설정된 흐름을 포함하십시오. 기존 연결이 항상 새 정책을 따르지는 않습니다. 터널이 내려가 있을 때 실패하는 브라우저는 하나의 데이터 점이며, 다른 모든 경로가 차단되었다는 증거가 아닙니다.

마지막으로, 변경 중인 네트워크 경로에 의존하지 않는 복구 방법을 유지하십시오. 로컬 저장소의 알려진 양호한 구성과 그것을 로드하는 문서화된 방법이 잠금을 정책으로 바꿉니다. 그것이 없으면 잘못된 개정 하나가 보호되어야 했던 머신에서 관리자를 잠그게 합니다.