VPN에서 캐스팅이 멈출 때: 검색, 제어, 스트림 중 어디인가
수신기가 보이지 않는 경우, 세션이 거부되는 경우, 재생이 도중에 멈추는 경우는 실패 지점이 다릅니다. VPN 정책이나 네트워크를 바꾸기 전에 단계부터 밝히세요.
캐스팅 문제는 소파에서 보면 똑같아 보이는 세 지점에서 생깁니다. 휴대전화가 수신기를 아예 보지 못할 수도 있고, 수신기가 나타났다가 세션을 거부할 수도 있으며, 세션이 시작된 뒤 일 분 후에 멈출 수도 있습니다. 휴대전화의 터널은 각 경로에 서로 다르게 영향을 주며, 그중 하나에는 아무 영향도 주지 않습니다. 먼저 실패하는 단계를 밝히고, 그다음에 정책 변경이 정말 올바른 수단인지 판단하세요.
정책을 바꾸기 전에 실패하는 단계를 밝히기
캐스팅 아이콘을 누른 직후 휴대전화가 무엇을 하는지 보세요. 목록이 비어 있으면 검색 결과이고, 실패를 알리는 탭은 제어 결과이며, 멈추기 전에 시작되는 세션은 재생 결과입니다. 이 셋은 담당이 다르고, 보통 처음 두 개만 휴대전화의 터널 설정과 관련됩니다.
| Stage | What the phone shows | Evidence that separates it |
|---|---|---|
| Discovery | No receiver in the list | Another device on the same segment sees the receiver |
| Control | Receiver listed, session refused | Port answer versus permission prompt |
| Playback | Session starts, then stalls | The receiver's own link, not the phone's |
무엇이든 바꾸기 전에 단계를 적어 두세요. 잘못된 단계에 적용한 수정은 다음 테스트를 읽을 수 없게 만들며, 캐스팅에 관한 속설 대부분은 바로 이 혼동에서 나옵니다.
검색은 로컬 트래픽이고, 터널은 그것을 숨긴다
수신기는 로컬 알림으로 자신을 알리고 휴대전화는 같은 링크에서 보내는 질의로 그것을 찾습니다. 따라서 휴대전화를 그 링크에서 떼어내는 것은 수신기도 목록에서 떼어냅니다. 모든 트래픽을 LAN 밖으로 보내는 터널은 이런 교환을 숨길 수 있고, 앱 수준의 로컬 네트워크 권한은 경로가 있어도 그것을 막습니다. 클라이언트 격리가 있는 게스트 Wi-Fi는 VPN 없이도 같은 빈 목록을 만듭니다. 터널을 탓하기 전에 두 기기가 같은 세그먼트를 공유하는지 증명하세요.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTR첫 번째 명령은 보조 기기의 세그먼트에서 무엇이 자신을 알리는지 나열하고, 두 번째는 멀티캐스트 DNS 그룹에 직접 질의합니다. 둘 다에 없으면 휴대전화 앱에도 나타나지 않으며, 터널 상태와 무관합니다. 터널이 꺼진 기기에서는 보이고 켜진 기기에서는 보이지 않는다면 단계와 원인을 함께 찾은 것입니다.
LAN 예외는 터널을 켜 둔다
많은 클라이언트는 터널을 활성 상태로 두면서 로컬 주소를 허용하는 로컬 네트워크 예외를 제공합니다. 킬 스위치나 방화벽 전체를 끄는 대신 그 문서화된 설정을 사용하세요. 그것들은 캐스팅에 필요한 것보다 훨씬 많은 것을 바꿉니다. 네트워크가 스마트 기기를 의도적으로 분리한다면, 평평한 접근이 아니라 검색·제어·반환 트래픽을 구체적으로 관리자에게 요청하세요.
nc -vz 192.168.1.50 8009수신기에 대한 제어 테스트는 허용과 도달 가능성을 구분합니다. 응답하는 포트는 경로가 있음을 뜻하고, 거부는 기기 검색은 허용되었지만 여전히 통신할 수 없음을 뜻합니다. 8008과 8009가 일반적인 캐스팅 포트이고 앱이 다른 포트를 쓸 수도 있으므로, 포트 하나의 거부는 판정이 아니라 단서로 받아들이세요. 예외와 앱 권한은 독립적입니다. 로컬 접근을 허용해도 경로가 생기지 않고, 경로를 추가해도 권한이 생기지 않습니다. 킬 스위치는 재연결 후 로컬 트래픽을 떨어뜨릴 수 있으므로 터널이 돌아오면 검색을 다시 테스트해야 합니다.
재생이 휴대전화의 연결을 쓰지 않을 수 있다
앱이 지시하는 세션에서는 휴대전화가 수신기에 미디어 주소를 넘기고 수신기가 자기 연결로 가져오므로, 휴대전화의 공인 주소를 바꿔도 스트림에는 아무 효과가 없습니다. 계정 제한이 있는 작품은 그 자체의 이유로 실패할 수 있고, Google의 캐스팅 요구 사항 은 네트워크 경로가 아니라 앱과 기기의 호환성을 다룹니다. 텔레비전 자체를 터널로 보내는 것은 별도의 구성이며 고유한 정책 질문이 따릅니다.
두 가지 단서가 모드를 구별합니다. 휴대전화 화면을 잠가도 이어지는 캐스팅은 수신기가 직접 가져오는 앱 지시형입니다. 보낸 기기의 화면 잠금에서 멈추는 미러링은 휴대전화에서 오는 연속 스트림입니다. 검색과 제어는 성공하는데 재생이 멈춘다면, 대신 수신기의 Wi-Fi 링크와 인터넷 경로를 보세요. 휴대전화에서 한 속도 테스트는 텔레비전이 아니라 휴대전화를 설명합니다.
예외를 되돌리고 다시 테스트하기
모든 임시 변경에는 되돌릴 길이 필요하고 순서도 중요합니다. LAN 예외를 제거하고 클라이언트가 정책을 다시 적용하도록 터널을 다시 연결한 다음, 검색 단계를 반복하고 수신기가 다시 사라지는지 기록하세요. 그 순서가 예외가 일을 했는지, 아니면 그 사이 다른 것이 바뀌었는지 알려 줍니다.
# after removing the LAN exception, reconnect and confirm the tunnel is up
resolvectl status | grep -E 'DNS Servers|Default Route|Protocols'
avahi-browse -at | grep -i -E 'chromecast|googlecast'그다음 세 단계를 따로 검증하세요. 하나를 통과해도 나머지에 대해서는 아무것도 말해 주지 않습니다. 이어서 무관한 휴대전화 앱이 여전히 의도한 경로를 따르는지 확인하세요. 조용히 완전한 우회로가 된 로컬 예외는 탭 한 번이 더 필요한 캐스팅보다 나쁜 결과입니다.