Mac Mail, 두 개의 계정 그리고 나눌 수 없는 하나의 VPN 규칙

Mail이 열리고 업무 받은편지함이 동기화되지만 개인 받은편지함은 시간 초과가 나기 시작한다. 또는 둘 다 동기화되지만 업무 서버는 터널이 올라와 있는 동안에만 응답하고, Mail은 어느 계정이 어느 것인지 알지 못한다. 증상은 늘 같은 모양, 즉 하나의 앱, 두 개의 계정, 그리고 앱을 식별하는 규칙이다. 해결은 앱이 경계가 아니라 용기라는 사실을 인정하는 데서 시작한다.

여기에는 세 가지 선택자가 작동하며, 서로 바꿔 쓸 수 없다. 하나는 연결을 만드는 프로세스이고, 또 하나는 도달하는 호스트이며, 세 번째는 그 호스트를 통해 로그인하는 데 쓰이는 신원이다. 정책이 지목할 수 있는 것이 바로 실제로 만들 수 있는 경계다.

왜 앱이 잘못된 단위인가

Mail은 구성된 모든 계정을 처리하는 단일 프로세스다. 앱을 대상으로 작성된 규칙은 그 모든 연결을 잡아내므로, 개인 계정이 업무 터널과 그 기본 경로를 물려받는다. 그것이 받아들일 만할 수도 있지만, 이는 결정이지 검토하지 않고 둘 수 있는 부작용이 아니다.

무엇이든 고치기 전에 사용자가 실제로 무엇을 불평하는지 확인하라. 동기화는 되지만 보낼 수 없는 받은편지함은 보통 받은편지함이 아니라 발송 서버를 가리키며, 둘 다 같은 사설 대역 안의 다른 주소에 있을 수 있다. 실패가 수신인지 발송인지 둘 다인지 물어라. 그 답이 규칙이 어떤 엔드포인트를 덮어야 하는지 결정하며, 서버 관리자와의 왕복 한 번을 아낀다.

두 계정이 서로 다른 서버를 쓸 때

업무 메일이 사내 대역 안의 호스트와 통신하고 개인 메일이 공개 제공자와 통신한다면, 목적지 기반 구성으로 요구 사항을 표현할 수 있다. 메일 서버의 실제 주소, 이를 해석하는 DNS, 같은 서비스에 딸린 발송 또는 인증 엔드포인트가 필요하다. 받은편지함만 덮는 규칙은 첫 발송에서 실패하므로 정책을 쓰기 전에 셋을 모두 모아라.

주소를 사용하라, @ 기호 뒤의 부분이 아니라. 메일 주소의 도메인은 라우팅 선언이 아니며, 그렇게 취급하면 잘못된 호스트에 발동하거나 전혀 발동하지 않는 규칙이 된다. 실제 엔드포인트는 계정 설정이나 관리자에게 확인하라.

두 계정이 하나의 서버를 공유할 때

같은 호스트 주소의 두 계정은 목적지 기반 선택을 완전히 무력화한다. 그 주소로 가는 경로는 연결하는 누구에게나 제공되며, 나중에 어느 사서함이 로그인하는지 검사할 수 없다. 경로를 옮기면 두 계정의 길이 함께 옮겨지며, 그것이 바로 사용자가 피하려던 결과다.

그 시점에서 정직한 선택은 플랫폼과 클라이언트가 지원한다면 계정 인식 정책, 앱 경계를 실제로 만들기 위해 업무 계정용으로 별도 승인된 메일 클라이언트, 또는 두 계정이 함께 이동한다는 사실을 받아들이는 것이다. 하나를 의도적으로 고르고 어느 것을 골랐는지 말하라.

터널을 켜는 것은 그것을 덮는 것과 같지 않다

Apple의 App Layer VPN 페이로드는 MailDomains 설정을 문서화한다: 목록에 있는 도메인은 지원되는 관리형 배포에서 Mail이 VPN 연결을 켜게 한다. 유용한 기능이지만 들리는 것보다 좁다. Mail이 그 도메인과 통신할 때 터널을 시작할 뿐, 모든 경로나 모든 앱 연결, 터널이 내려가 있을 때 일어나는 일을 설명하지는 않는다.

이것은 관리형 기능이기도 하며, Mail 인터페이스의 계정별 체크박스가 아니다. 배포가 관리형이 아니면 그 설정은 사용할 수 없고, 프로필을 아무리 편집해도 생기지 않는다.

캐시된 받은편지함이 아니라 새 동기화로 시험하라

수용 시험은 의도한 정책 아래 각 계정의 새 동기화와, 보호된 계정의 사용 불가 상태다. 캐시된 받은편지함은 다음 요청에 대해 아무것도 증명하지 못하며, 연결된 VPN 아이콘은 어떤 터널이 존재한다는 것만 말한다.

관리자에게 업무 계정의 엔드포인트와 개인 메일에 원하는 동작을 주고, 지원되는 계정 인식·도메인 기반·애플리케이션 정책 중 무엇이 이를 구현하는지 물어라. 두 계정이 각 조건에서 동기화되는 것을 보는 것이 설계한 경계가 기계가 강제하는 경계임을 보여 주는 유일한 증거다.