FaceTime은 되는데 Mac에서 iPhone으로 전화를 걸 수 없을 때

Mac에서 FaceTime 음성 통화를 아무 문제 없이 시작하고, 이어서 같은 Mac에서 배관공 번호를 눌러도 아무 일이 일어나지 않을 수 있습니다. 흔한 해석은 네트워크가 건강하고 무관한 무언가가 고장 났다는 것입니다. 그 해석이 바로 속설이고, 대개 FaceTime이 공정한 시험처럼 보이기 때문에 살아남습니다.

그렇지 않습니다. FaceTime 음성과 전화 통화 릴레이는 요구 사항이 다른 별개의 전송 방식이며, 하나는 다른 하나가 건널 수 없는 터널을 통과합니다.

VPN도 기본적으로 범인이 아닙니다. 아래 순서는 다른 설정을 건드리기 전에 두 가지 가정을 모두 없앱니다.

FaceTime이 되어도 알 수 있는 것은 거의 없습니다

FaceTime 음성은 도달 가능한 상대와 연결을 협상합니다. 양 끝이 패킷을 주고받을 수 있으면 그 트래픽은 인터넷을 지날 수 있고 전체 터널 VPN도 통과합니다. 전화 통화 릴레이는 건물을 떠나지 않습니다. Mac은 근처 iPhone에 자기 셀룰러 회선으로 통화를 걸어 달라고 요청하고, 그 요청은 로컬입니다.

따라서 성공한 FaceTime 통화는 Mac에 쓸 만한 인터넷이 있고 Apple 서비스에 도달한다는 것만 증명합니다. 옆에 있는 iPhone을 보는지는 아무것도 말하지 않습니다. 두 기기는 같은 SSID를 공유하면서도 서로 보이지 않을 수 있습니다.

속설 전체가 한 줄에 있습니다. 건물을 떠나는 통화는 로컬 연결을 전혀 시험하지 않습니다.

릴레이 경로가 실제로 요구하는 것

Apple 목록의 모든 항목은 필수이며 추가 사항이 아닙니다. 두 기기가 같은 Wi-Fi 네트워크에 있고, 둘 다 같은 Apple 계정으로 로그인했고, 둘 다 전화번호를 켠 FaceTime에 로그인했으며, 쓰려는 Mac에서 다른 기기에서의 통화가 켜져 있어야 합니다. Apple의iPhone 통화 안내서가 현재 문구의 출처입니다.

최신 iPhone에서는 스위치가 설정, 앱, 전화, 다른 기기에서의 통화에 있고, Mac이 그 목록에 나타나 켜져 있어야 합니다. Mac이 처음 회선을 쓰려 하면 macOS가 그 iPhone에서의 통화를 허용할지 묻습니다. 이 요청을 한 번 닫으면 다시 묻지 않으므로 기능은 조용히 고장 난 채로 남습니다.

Mac 쪽은 시스템 버전에 따라 다릅니다. 최신 macOS는 전화 앱을 제공하고, 오래된 버전은 FaceTime으로 통화를 보냅니다. 안내서가 찾을 수 없는 메뉴를 가리키면 설정이 없다고 단정하기 전에 버전을 확인하세요.

VPN이 실제로 방해하는 곳

VPN 클라이언트는 세 가지 방식으로 릴레이를 깨뜨릴 수 있고, 문서화된 것은 첫 번째뿐입니다. 문서화된 사례는 로컬 네트워킹을 막는 구성입니다. macOS는 그런 VPN이 Continuity 기능을 방해할 수 있다고 경고하며, 릴레이는 Continuity 기능입니다. 두 번째는 전체 터널로,Mac이 iPhone에 닿으려고 쓰는 트래픽을 붙잡습니다그래서 로컬 요청이 아무 쓸모도 없는 게이트웨이로 나갑니다. 세 번째는 필터나 킬 스위치를 터널에만이 아니라 모든 인터페이스에 적용하는 클라이언트입니다.

회사 서브넷만 실어 나르는 분할 터널은 보통 로컬 경로를 그대로 둡니다. 그래서 같은 Mac이 한 VPN 프로필에서는 통과하고 다른 프로필에서는 실패하며, 두 프로필의 차이가 유용한 신호입니다.

비교가 무엇을 증명하는지에 엄격해야 합니다. VPN 없이 되고 VPN을 켜면 실패하는 것은 상호작용이지 진단이 아닙니다. 차단된 프로토콜이나 포트, 인터페이스를 지목하지 않으며, 그것만으로 경로를 지어내면 다음 시험이 무의미해집니다.

VPN 탓으로 돌리는 세 가지 실패

Wi-Fi 통화. 이것은 iPhone의 통신사 기능이며 Mac이 물려받는 것이 아닙니다. 휴대폰이 통신사 서비스를 Wi-Fi로 쓰게 해 주고, 모든 통신사가 제공하지는 않으며, iPhone이 꺼져 있거나 범위를 벗어났거나 통신사 엔드포인트를 막는 네트워크에 있으면 쓸모가 없습니다. 진짜 요구가 iPhone을 집에 두고 통화하는 것이라면 릴레이는 처음부터 잘못된 수단을 시험한 셈입니다.

네트워크 격리. 게스트 네트워크, 액세스 포인트의 클라이언트 격리, 별도 VLAN은 릴레이 증상을 그대로 만듭니다. 같은 SSID에 서로 보이지 않고 VPN은 관계없습니다. 건물 Wi-Fi가 클라이언트를 격리한다면 Mac 설정으로는 결과가 바뀌지 않습니다.

Handoff. Handoff는 기기 사이에서 작업을 이어 갑니다. Mac에 셀룰러 회선을 주는 것도 아니고 대체 시험도 아닙니다. Handoff 아이콘이 뜨는 것은 두 기기가 서로를 찾을 수 있다는 뜻이니 알아 둘 만하지만, 통화 라우팅이 된다는 증명과는 거리가 멉니다.

증거가 남는 시험 순서

알려진 상태에서 시작합니다. iPhone은 잠금을 풀고 가까이 두고, 두 기기를 같은 Wi-Fi에 연결하고, Mac의 VPN은 끕니다. 발신 한 번, 수신 한 번을 합니다. 실패 이유가 다르므로 양방향이 모두 의미 있습니다. 발신은 Mac이 회선에 닿느냐에, 수신은 iPhone이 그 Mac을 유효한 대상으로 보느냐에 달려 있습니다.

실제로 쓰는 프로필로 VPN을 다시 연결하고 다른 것은 바꾸지 않은 채 두 통화를 반복합니다. 둘 다 되면 VPN은 변수가 아니므로 조정을 멈춰야 합니다. 둘 다 깨지면 프로필 이름, 클라이언트 버전, 로컬 트래픽 제외 여부를 기록하고 그 세 가지를 구성의 주인에게 넘기세요.

한 방향만 실패하면 터널보다 iPhone 통화 설정을 먼저 봅니다. 비대칭 실패는 라우팅 문제보다 기기별 스위치인 경우가 훨씬 많고, 그 관찰 하나로 반나절이 절약됩니다.

에스컬레이션 전에 확인할 것

다음 다섯 항목을 차례로 확인하고 각각의 답을 적습니다. 같은 Wi-Fi 네트워크, 같은 Apple 계정, FaceTime에서 켜진 전화번호, 다른 기기에서의 통화에서 켜진 이 Mac, macOS 허용 요청 수락. 확인할 수 없는 것은 모두 무료 후보 원인입니다.

그다음 무엇을 우선할지 정합니다. 통화가 책상에서만 되면 되면 VPN 프로필에서 로컬 트래픽을 빼는 것으로 보통 충분하고 터널의 목적도 약해지지 않습니다. iPhone이 다른 곳에 있을 때도 되어야 한다면 릴레이는 맞지 않는 기능이고 통신사 문제를 먼저 생각해야 합니다.