VPN이 연결되면 Handoff가 멈춘다: 무엇을 확인해야 하나

iPhone에서 페이지를 열고 Mac 옆으로 가도 Dock 아이콘이 나타나지 않는다. VPN을 끄면 작동한다. 이 흐름은 VPN 문제처럼 보이고 실제로 그런 경우도 많지만, 사람들이 생각하는 이유 때문은 아니다. Handoff는 기기 간 로컬 기능이고, 터널은 인터넷 쪽이 아니라 로컬 쪽을 방해한다.

작업 하나와 기기 한 쌍으로 좁힌다

Handoff를 지원하는 작업 하나, 예를 들어 Safari의 웹 페이지나 Notes의 초안을 고르고, 기기도 한 쌍만 쓴다. 앱, 계정, 물리적 위치는 같게 두고 변수는 한 번에 하나만 바꾼다. 세 가지를 동시에 바꾸는 테스트는 쓸 수 없는 관찰만 남긴다.

Handoff는 작업 이어가기이지 화면 캐스팅이나 파일 공유가 아니다. 요구 사항이 화면 미러링이나 공유 마운트라면 전제 조건이 다른 다른 기능을 디버깅하는 것이다.

정확한 작업을 적어 둔다. 어떤 수정이든 같은 작업이 되어야 검증되기 때문이다.

전제 조건은 로컬이지 원격이 아니다

Apple의 Handoff 요구 사항은 가까운 호환 기기, 양쪽의 Wi-Fi와 Bluetooth 켜짐, 같은 Apple Account 로그인, Handoff 켜짐이다. 공유 Mac에서는 다를 수 있으므로 앱을 산 계정이 아니라 Continuity에 쓰는 계정을 확인한다. 그다음 앱과 작업이 실제로 Handoff를 지원하는지 확인한다. 임의의 앱이 열려 있다는 것만으로는 아무것도 증명되지 않는다. 이런 확인은 비용이 적고, 가장 먼저 배제해야 할 항목이다.

이 모든 것은 로컬 무선으로 이루어진다. Bluetooth가 활동을 알리고 Wi-Fi가 데이터를 나르므로, 둘 다 인터넷이 있어도 기기는 가까이 있어야 한다.

이 중 어느 것도 어느 기기가 쓰는 공인 주소에 의존하지 않는다.

VPN 클라이언트가 로컬 트래픽에 하는 일

전체 터널 클라이언트는 다른 모든 것과 함께 로컬 서브넷까지 잡을 수 있고, 로컬 네트워크 접근을 허용하지 않으면 정확히 그렇게 하는 클라이언트도 있다. Apple은 로컬 네트워킹을 막는 VPN 구성이 Continuity 기능을 방해할 수 있다고 경고한다. 이것은 클라이언트 정책에 대한 진술이지 특정 포트가 막힌다는 말이 아니다.

많은 클라이언트가 로컬 접근 예외를 제공한다. 활성화하기 전에 무엇을 허용하는지 읽고, 방화벽 규칙을 직접 고치는 것보다 공급업체가 지원하는 옵션을 우선한다.

클라이언트에 그런 옵션이 없다면 설계 결정은 배포를 소유한 쪽에 있다.

공유 출구가 주지 않는 것

같은 VPN 서버를 쓰는 두 기기는 출구 주소를 공유하고, 공유하는 것은 그것뿐이다. 그것은 Bluetooth 알림을 만들지 않고, 같은 로컬 링크에 두지 않으며, 맞지 않는 Apple Account도 고치지 않는다. 공통 공인 주소를 전제로 보는 것은 범주 오류이고, 쓸모없는 클라이언트 변경으로 이어진다.

VPN 서비스의 가입자 격리도 가까운 두 기기가 작업을 이어가는 것과는 다른 문제이므로, 가입자 간 전달을 여는 것은 Handoff 단계가 아니다.

라우터 기반 VPN은 기기에 어떤 정책이 적용되는지를 바꿀 뿐, 빠진 무선이나 계정을 제공하지는 않는다.

정책 소유자와 결정하고, 그다음 두 결과를 모두 검증한다

수정은 세 조건으로 결정된다. VPN을 끈 상태에서 전제 조건 사슬이 유지되는가. 클라이언트에 지원되는 로컬 접근 옵션이 있고 정책이 그것을 허용하는가. 그리고 터널이 존재하는 이유인 보호를 약화하지 않고 변경을 검증할 수 있는가. 세 번째 답이 아니오라면 변경에는 우회가 아니라 관리자가 필요하다.

승인된 변경 뒤에는 두 결과를 모두 확인한다. 작업은 가까운 기기에서 이어지고, 터널이 필요한 앱은 의도한 접근과 차단을 유지한다.

예외는 그 연결의 구성 옆에 기록한다. 그렇지 않으면 다음 프로파일 업데이트가 조용히 지운다.