VPN 속 스마트 TV: 캐스팅과 DNS가 따로 깨지는 이유

텔레비전에는 해외 카탈로그가 보이는데, 휴대폰의 캐스트 버튼에는 더 이상 나타나지 않습니다. 두 불만 모두 라우터의 네 페이지에 있는 네 가지 설정을 지목하는 한 문장에서 시작합니다. 출구를 고치면 검색이 깨지고, 검색을 고치면 다음 임대가 출구를 다른 기기로 넘깁니다. 아래 순서는 선택기에서 캐스팅 경로로 이어집니다.

네 가지 결정이 각각 사는 곳

메뉴를 열기 전에 넷을 적어 두십시오, 각각 다른 페이지에 있고 다른 지점에서 실패하기 때문입니다. 선택기는 터널이 어느 클라이언트에 적용되는지 고르고, 리졸버는 이름을 어디서 응답할지 정하며, 주소 패밀리는 IPv6가 아예 포함되는지 정하고, 로컬 경로는 휴대폰과 TV가 여전히 서로를 보는지 정합니다. 하나를 바꾸면 지금 서 있는 페이지에서는 완료처럼 보입니다. 나머지 셋의 피해는 나중에, 다른 메뉴에서, 다른 불만으로 나타납니다.

펌웨어 메뉴는 달라도 네 위치는 좀처럼 달라지지 않습니다. 선택기는 DHCP 서버의 정적 매핑과 그것에 맞는 방화벽 규칙입니다. 리졸버는 DNS 서비스 옆에 있으며, 포워더 항목이나 업스트림 서버 목록이 라우터가 어떤 이름에 응답하고 질의가 어디서 나가는지를 정합니다. 패밀리 설정은 인터페이스 자체에 속하며, IPv4와 IPv6가 따로 구성되고 정책은 첫 번째만 포함할 수 있습니다. 로컬 경로는 액세스 포인트 스위치로, 클라이언트 격리이거나 자체 방화벽이 있는 게스트 네트워크입니다.

선택기가 임대보다 오래 살게 하세요

기기별 정책과 전용 세그먼트 둘 다 작동하며, 더 나은 선택은 두 번째 사람이 기억하지 않아도 펌웨어가 유지할 수 있는 것입니다. 함정은 DHCP 서버가 자체 일정으로 준 주소에 고정된 규칙입니다. 임대가 움직일 때까지 작동하다가, 소유자가 볼 수 없는 이유로 노트북을 다른 나라를 거쳐 라우팅하는데, 정돈이 아니라 지속성이 최적화할 가치가 있는 속성입니다.

예약과 규칙을 하나의 변경으로 보내십시오, 예약보다 오래 사는 규칙은 다른 사람의 하드웨어를 겨눈 규칙이기 때문입니다. 세그먼트 전체 규칙은 가장 오래가고 가장 거친 선택기이며, 그 인터페이스 뒤의 모든 기기가 필요 여부와 상관없이 출구를 물려받습니다. 어떤 선택기를 고르든 다음은 커버리지 질문입니다: IPv4만의 정책은 절반의 결정이고, 포함되지 않은 패밀리가 아무도 모르게 떠나는 쪽입니다.

TV가 실제로 어느 리졸버를 쓰는지 알아내세요

라우터를 만지기 전에 TV 자체의 네트워크 설정을 여십시오, 이 논쟁을 끝내는 것은 기기입니다. 수동으로 설정한 DNS 필드는 DHCP가 무엇을 주든 그 서버를 계속 쓰고, 한 번 다른 지역용으로 구성된 셋톱박스는 여전히 응답하지 않는 주소를 가리킬 수 있습니다. 필드가 자동이면 라우터의 DHCP 옵션이 정하고, 라우터 자체 리졸버가 다음 질문이 됩니다. 어느 쪽이든 답은 기기 화면에 있고 펌웨어 설명서에는 없습니다.

라우터 쪽에서 중요한 구분은 라우터가 스스로 응답하는 이름과 그가 전달하는 이름 사이입니다, 이 두 경로는 다른 인터페이스로 나갈 수 있기 때문입니다. 그래서 올바르게 해석되는 조회는 미디어 요청이 어디로 가는지 아무것도 말하지 않으며, Linux 게이트웨이에서는 정책 테이블과 단 한 번의 경로 조회가 TV에서 아무것도 잡지 않고 두 질문에 답합니다:

ip rule show
ip route get 203.0.113.10

첫 번째 명령은 TV 트래픽을 표시하는 규칙을 위해, 두 번째는 예시 주소로 가는 패킷이 실제로 쓸 인터페이스를 위해 읽으십시오. 둘이 어긋나면 리졸버가 아니라 정책이 원인입니다. 한 가지를 바꾼 뒤 쌍을 다시 실행하십시오, 규칙 목록은 순서에 민감하고 새 항목이 트래픽을 나르던 규칙을 가릴 수 있습니다. 목적지는 문서용으로 예약되어 있으므로 붙여 넣은 출력은 예시로 읽힙니다.

캐스팅은 스트림이 아니라 검색에서 깨집니다

캐스팅은 최소 세 번의 대화이고 그중 하나만 영상을 나릅니다. 휴대폰은 로컬 세그먼트에서 멀티캐스트나 브로드캐스트로 TV를 찾고, 무엇을 재생할지 말하는 제어 채널을 연 뒤, TV가 스트림을 스스로 가져오거나 휴대폰에서 중계받습니다. 검색은 그 트래픽을 전달하지 않는 라우터를 결코 넘지 않습니다, 그래서 TV가 의도한 대로 라우팅되면서도 캐스트 목록에 결코 나타나지 않을 수 있습니다.

게스트 네트워크와 클라이언트 격리가 흔한 원인이며, 둘 다 구성된 대로 정확히 작동합니다. 기기 하나가 다시 보이도록 무선 네트워크 전체에서 격리를 끄는 것은 흔한 과잉 수정이고, 그 설정이 닫으려던 모든 휴대폰 간 경로를 다시 엽니다. 더 좁은 답이 있습니다: 두 주소 사이의 검색 및 제어 트래픽에 대한 통과 규칙, TV용 별도 SSID, 또는 게스트 네트워크의 문서화된 예외 하나입니다.

격리 규칙이 아직 있는 상태에서 캐스팅을 시험하고, 그다음 검색 예외만 추가해 다시 시험하십시오. 두 번째 시도에서 TV를 찾으면 예외가 해결책이고 나머지 세그먼트는 그대로 둘 수 있습니다.

터널을 멈추고 어느 쪽으로 실패하는지 보십시오

마지막 점검은 대부분의 구성이 건너뛰는 것입니다: 터널을 내리고 TV가 멈추는지, 아니면 로컬 연결로 조용히 나가는지 보십시오. 선호를 표현하는 정책은 열린 채 실패하고, 출구가 ISP로 돌아가는 동안 재생이 계속되므로 그 실패를 놓치기 쉽습니다. 킬 스위치 규칙은 대신 닫힌 채 실패하며, 터널이 돌아올 때까지 TV는 아무것도 보고하지 않습니다. 두 동작 중 어느 것도 틀리지 않았지만, 어느 쪽을 구성했는지 모르는 것이 틀렸습니다.

변경 후 네 가지를 이 순서로 다시 확인하십시오. 다음 임대나 재부팅 후에도 선택기가 기기와 일치하는지. 리졸버가 정책이 의도한 경로에서 응답하고 기기가 기억한 서버에서 응답하지 않는지. 정책의 주소 패밀리가 TV와 액세스 네트워크가 실제로 쓰는 모든 패밀리를 포함하는지. 캐스팅이 실제로 사용할 휴대폰에서 TV를 찾고 같은 SSID의 시험용 휴대폰에서 찾지 않는지.

그 네 줄은 채팅 스레드가 아니라 라우터 구성 옆에 두십시오: 규칙이 무엇과 일치하는지, TV가 어느 리졸버에 묻는지, 어느 패밀리가 포함되는지, 캐스팅에 어떤 로컬 경로가 필요한지. 다음에 방화벽을 여는 사람은 티켓을 읽기 훨씬 전에 구성을 읽을 것입니다. 그때 그 사람이 바로 당신일 수 있습니다.