VPN 上的智能电视：投屏与 DNS 为何分别出问题

电视能看到海外片库，手机的投屏按钮却再也列不出它。两种抱怨都源于同一句话，而这句话牵涉路由器四个页面上的四项设置。修好出口，发现就断；修好发现，下一次租约又把出口交给别的设备。下面的顺序从选择器一直走到投屏路径。

四项决定各自住在哪里

打开菜单前先把这四项写下来，因为它们各自住在不同页面，也各自在不同地方出问题。选择器决定隧道作用于哪台客户端，解析器决定域名在哪里被回答，地址族决定 IPv6 是否被覆盖，本地路径决定手机和电视还能不能互相看见。只改一项时，从当前页面看好像已经完成；另外三项的破坏会在之后、在另一个菜单里、以另一种抱怨出现。

固件菜单各不相同，但这四个位置很少变。选择器是 DHCP 服务器上的静态映射，加上与之匹配的防火墙规则。解析器位于 DNS 服务旁，由转发条目或上游服务器列表决定路由器回答哪些域名、查询从哪里发出。地址族设置属于接口本身，IPv4 与 IPv6 分别配置，策略可能只覆盖前者。本地路径则是接入点交换机，要么是客户端隔离，要么是带独立防火墙的访客网络。

让选择器活得比租约更久

按设备策略和专用网段都可行，更好的选择是固件能在没有第二个人记着的情况下维护的那一种。陷阱在于把规则钉在 DHCP 服务器按自己的时间表发出的地址上：租约一动它就失效，随后又因为物主看不见的原因把笔记本从另一个国家绕出去。值得优化的属性是持久，而不是整齐。

把地址预留和规则作为一次变更一起下发，因为比预留活得更久的规则，瞄准的是别人的硬件。整段规则是最持久也最粗放的选择器，因为该接口后面的每台设备都会继承出口，不管它需不需要。无论选哪种选择器，接下来都是覆盖问题：只覆盖 IPv4 的策略只是半个决定，而没被覆盖的那个地址族正是悄悄离开的那一个。

弄清电视真正使用的是哪个解析器

动路由器之前，先打开电视自己的网络设置，因为这件事由设备来裁决。手动填写的 DNS 字段会继续使用那台服务器，不管 DHCP 提供什么；而曾经为另一个地区配置过的机顶盒，可能仍指向一个不再应答的地址。如果字段是自动的，就由路由器的 DHCP 选项决定，路由器自己的解析器便成为下一个问题。无论哪种情况，答案都在设备屏幕上，而不在固件手册里。

在路由器这一侧，真正重要的区别是 路由器自己回答的域名与它转发的域名 之间的差别，因为这两条路径可能从不同接口出去。所以一次正确解析的查询并不能说明媒体请求去了哪里；在 Linux 网关上，策略表加一次路由查询就能同时回答这两个问题，而不必在电视上抓任何包：

ip rule show
ip route get 203.0.113.10

第一条命令读的是标记电视流量的规则，第二条读的是发往示例地址的包实际会走哪个接口。两者不一致时，错的不是解析器，而是策略。改一处，再把这一对命令跑一遍，因为规则列表对顺序敏感，新条目可能遮住原本承载流量的那条规则。目的地址是文档保留段，所以粘贴出来的输出可以当作示例来读。

投屏是在发现环节断的，不是在码流上

投屏至少包含三段对话，只有一段传视频。手机在本地网段通过组播或广播发现电视，打开控制通道说明要播什么，随后电视要么自己去取流，要么接收手机转发过来的流。发现永远跨不过一台不转发该流量的路由器，这正是电视可以被完全按意图路由、却始终不出现在投屏列表里的原因。

访客网络与客户端隔离是常见原因，而且两者都在按配置行事。为了让一台设备重新出现而关掉整个无线网络的隔离，是常见的过度纠正，它会重新打开这项设置本来要关掉的每一条手机到手机路径。存在更窄的答案：为两个地址之间的发现与控制流量放行一条规则、给电视单独一个 SSID，或者在访客网络上记录一条例外。

在隔离规则仍然生效时测试投屏，然后只加入发现例外再测一次。如果第二次能找到电视，例外就是修复方案，网段其余部分可以保持原样。

停掉隧道，看它往哪一边坏

最后一项检查是大多数配置会跳过的：把隧道停掉，看电视是停住，还是悄悄从本地连接出去。表达偏好的策略是开放失败，而这种失败很容易被忽略，因为出口退回 ISP 时播放仍在继续。kill-switch 规则则是关闭失败，电视在隧道恢复之前什么都不报告。两种行为都不算错；不知道自己配的是哪一种才算错。

任何改动之后，按这个顺序复查四件事。下一次租约或重启之后，选择器仍然匹配这台设备。解析器在策略意图的路径上回答，而不是从设备记住的服务器回答。策略里的地址族覆盖电视和接入网络实际使用的每一个族。投屏仍然是从真正会用的那台手机去发现电视，而不是从同一 SSID 上的测试手机。

把这几行写在路由器配置旁边，而不是聊天记录里：规则匹配什么、电视问哪个解析器、覆盖哪个地址族、投屏需要哪条本地路径。下一个打开防火墙的人，会先读到配置，再读到工单。到那时，那个人可能就是你。