Featured image of post 通过 OpenWrt + rtp2httpd 打造全屋 IPTV：浙江电信组播转单播实战教程
Tech

通过 OpenWrt + rtp2httpd 打造全屋 IPTV：浙江电信组播转单播实战教程

想要在 Apple TV 等局域网设备上无缝观看电信 IPTV？本文以浙江电信为例，详解如何在 ESXi 下部署 OpenWrt，利用轻量级 rtp2httpd 转化组播源。内含完整 VLAN 组网拓扑与排障指南。

TL;DR: 传统的 IPTV 观看需要专属机顶盒和独立的物理线路，体验割裂。本文介绍了在 ESXi 环境下部署 OpenWrt，并结合 rtp2httpd 将组播源转换为 HTTP 单播信号的方案。最终实现 Apple TV 等局域网内任意终端直接无缝观看浙江电信 IPTV 直播。

解决的问题

传统的 IPTV 观看方式需要使用运营商提供的专属机顶盒（IPTV Box）连接电视才能观看，这导致了很大的局限性：不仅需要在路由器/交换机之间做网络隔离、拖网线，而且必须切信号源才能观看流媒体，体验十分割裂。

为了能在局域网内的任意设备（如 Apple TV、手机、电脑）上无缝观看 IPTV，我们可以通过 OpenWrt 的内网融合与开源项目 rtp2httpd 将组播源转换为 HTTP 单播信号，从而实现全屋共享 IPTV 信号。

环境背景

为了实现这一方案，本文的实践基于以下基础环境构建：

  • 核心网关：一台运行 ESXi 虚拟化的宿主机。
  • 软路由系统：x86 架构的 OpenWrt（本文使用纯净且兼容性良好的 ImmortalWrt）。
  • 网络设备：支持 VLAN 划分的可网管交换机。

读者提醒（Prerequisites）：本文包含一定的技术深度。为确保您能顺利完成部署，建议您已具备基本的 ESXi 虚拟化网络概念、了解基础的 VLAN 划分规则，并熟悉 OpenWrt CLI 的基础操作能力。

本文将以浙江电信 IPTV 为例，详细记录在 ESXi 虚拟化环境中部署 OpenWrt 并配置 rtp2httpd 的完整流程。

实施步骤

1. 抓包获取机顶盒鉴权信息

电信的 IPTV 机顶盒一般是直接连接在 GPON ONU (光猫) 的专用 IPTV 接口上的，这个接口通过 IPoE 方式让机顶盒获取 DHCP 分配的内网 IP 地址。

如果将普通电脑或终端直接接入这个网口，是无法获取到 IP 地址的。原因是电信局端会对 DHCP 请求进行鉴权，主要校验 DHCP Option 12 (Hostname) 和 Option 60 (Vendor Class) 的值。

因此，我们需要先通过抓包工具（如 Wireshark）或者光猫的管理后台抓包，获取自己机顶盒的以下关键信息：

  • MAC 地址：机顶盒背面的真实 MAC 地址
  • Option 12 (Hostname)：即机顶盒的 STB ID，一般也会直接印在机顶盒背面的标签码上。

Wireshark 抓包寻找 DHCP Vendor Class Identifier 示例

  • Option 60 (Vendor Class Identifier)：类似 16 进制的字符串。在 Wireshark 等抓包工具中找到对应 DHCP 报文，展开 Option: (60) Vendor class identifier，选中里面的 Vendor class identifier:，右键选择 Copy -> ...as Hex Stream。 复制到的内容应当是这种格式： 00001f3764925bbf3200000000622500000000000036c62b06e75f6f45cb4fdfb190045a51153196b05f5a7b5d5b6f699b5d003ed9c786007ee110

2. 在 ESXi 上部署 OpenWrt

我的 OpenWrt 是部署在 ESXi 6.7 上的。为了保证系统的稳定性以及对国内环境的良好兼容，我选择了 ImmortalWrt 这个较为纯净的分支。

  1. 下载镜像：前往镜像站下载最新的 ImmortalWrt 24.10.5 x86/64 固件，选择适合 ESXi 的 generic-ext4-combined.vmdk.gz。
  2. 格式转换：解压上传到 ESXi 数据存储后，需要开启 SSH 使用 vmkfstools 将 vmdk 转换成 ESXi 兼容的厚置备或精简置备格式。 例如，将其转换为精简置备（Thin Provisioning）的命令如下： 
    1

    vmkfstools -i immortalwrt-24.10.5-x86-64-generic-ext4-combined.vmdk openwrt.vmdk -d thin
  3. MAC 地址伪装：这是非常关键的一步！在 ESXi 中为 OpenWrt 虚拟机配置网卡时，找到用于连接 IPTV 接口的那张虚拟网卡，将其 MAC 地址手动修改为抓包获取到的机顶盒 MAC 地址，千万不要使用系统自动生成的 MAC。

3. 网络拓扑与 VLAN 配置

graph TD %% 物理硬件层 subgraph Physical_Layer [物理透传链路] ONU[GPON ONU 光猫] Mercury[水星 SG105 Pro 交换机] Huawei[华为交换机] ESXi_Host[ESXi 6.7 宿主机] end %% 虚拟化内部核心逻辑 subgraph ESXi_Internal [ESXi 虚拟环境] vSwitch((vSwitch0 虚拟交换机)) Main_VM[OpenWrt 主路由] IPTV_VM[IPTV-OpenWrt 旁路由] end %% 物理链路透传路线 ONU ---|IPTV 物理专用口 交换机打VLAN 13 TAG| Mercury Mercury ---|物理 Trunk 链路| Huawei Huawei ---|物理网线接入| ESXi_Host ESXi_Host ---|物理网卡| vSwitch %% 虚拟机与 vSwitch 的连接 (依靠 VLAN 划分业务) vSwitch ---|VLAN10: 承载 LAN 内部互通| Main_VM vSwitch ---|VLAN10: 承载 LAN 内部互通| IPTV_VM vSwitch ---|VLAN13: 承载 IPTV 组播信号| IPTV_VM %% 拨号逻辑 (单独标注业务走向) ONU -.->|PPPoE 逻辑链路| Main_VM %% 样式美化 style IPTV_VM fill:#f96,stroke:#333 style Main_VM fill:#bbf,stroke:#333 style vSwitch fill:#dfd,stroke:#333

为了将光猫的 IPTV 接口信号引入到虚拟机的 OpenWrt 中，我们需要划定 VLAN。

  1. ESXi 配置：在 ESXi 6.7 的网络设置中，创建一个名为 iptv 的端口组，并为其分配一个独有的 VLAN ID。
  2. 实体交换机配置：在连接 ESXi 宿主机的实体交换机上，同样需要配置此 VLAN。
  3. 物理连接：将光猫上的 IPTV 网口通过网线连接到实体交换机的一个端口上。
  4. 透传：通过交换机打上 VLAN 标签后，将链路透传到 ESXi 6.7 的 vSwitch 上，最终将这个专属的端口组分配给 OpenWrt 虚拟机的 IPTV 接口。

4. 安装与配置 rtp2httpd

rtp2httpd 是一个非常优秀的轻量级组播转单播工具。相较于传统的并行业界方案（如 udpxy 采用 fork-per-client 模型），它采用了更高效的事件驱动架构，在并发和资源占用上具有显著优势。

根据其官方性能测试（Benchmark）数据显示，在同等多流高负载下（例如独立处理 8 个并发 40Mbps 码率的组播流），基于 Ubuntu 24.04 on Apple M3 Max (Parallels Desktop 虚拟机) 环境下的测试结果：

  • 最高效的 CPU 算力：CPU 使用率仅约 msd_lite 的 66%、udpxy 的 16% 以及 tvgate 的 5%。
  • 极低的内存占用：即使全默认配置也可将内存开销稳定在 4MB 左右，非常适合部署于如 OpenWrt 这样硬件资源受限的嵌入式路由设备上。
  • 高带宽重载表现稳定：即便在处理高达 400 Mbps 单点高码率流转发的极端场景下，整体 CPU 占用也仅约 27%，为系统保留了充足的余量。
  • 便捷的内置 Web 播放器：除了卓越的转发性能，rtp2httpd 还内置了一个轻量级的 Web UI 播放器。这使得用户在完成基础配置后，可以直接通过浏览器实时预览和验证 IPTV 频道流，无需频繁切换到外部播放器（如 VLC 或 PotPlayer），极大地提升了调试效率。

在 OpenWrt 系统上，我们需要依次安装它的核心程序和配套的 LuCI 界面插件。

进入 OpenWrt 后台或使用 SSH，按顺序安装以下 3 个 ipk 文件：

  1. rtp2httpd_3.10.1-r1_x86_64.ipk：这是 rtp2httpd 的核心主程序，负责处理底层的组播流转单播 HTTP 流的转换逻辑。
  2. luci-app-rtp2httpd_3.10.1-r1_all.ipk：这是 OpenWrt LuCI 提供的一套 Web UI 管理界面，安装后可以在路由器后台拥有可视化的配置页面和控制面板。
  3. luci-i18n-rtp2httpd-zh-cn_3.10.1_all.ipk：这是 Web UI 界面的简体中文汉化包，安装后配置页面就会显示为中文。

5. 修改 DHCP 脚本完成 IPoE 鉴权

虽然我们在 ESXi 中已经修改了接口的 MAC 地址，但这还不够，我们需要让 OpenWrt 在发起 DHCP 请求时带上之前抓包获取的 Option 12 和 Option 60 字段。

由于 OpenWrt 默认的 LuCI 界面无法直接自定义这两个 DHCP 请求参数，我们需要修改底层脚本：

  1. 使用 SSH 或其他方式登入 OpenWrt 的 shell。

  2. 编辑文件 /lib/netifd/proto/dhcp.sh (代码大约位于第 72 行的 proto_dhcp_setup() 函数内)：

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

    proto_dhcp_setup() {
 # 省略
        proto_run_command "$config" udhcpc \
                -p /var/run/udhcpc-$iface.pid \
                -s /lib/netifd/dhcp.script \
                -f -t 0 -i "$iface" \
                ${ipaddr:+-r ${ipaddr/\/*/}} \
                ${hostname:+-x "hostname:$hostname"} \
                # ${vendorid:+-V "$vendorid"} \ # 原本是这样
                ${vendorid:+-V '' "-x 0x3c:$vendorid"} \  # 修改成这样
                $clientid $defaultreqopts $broadcast $norelease $dhcpopts
 # 省略
}

  3. 注意在 OpenWrt 的网络接口设置里补充 DHCP 鉴权参数及路由设置（在 OpenWrt 后台菜单：网络 -> 接口 -> 找到对应的 IPTV 接口点击编辑）：

    • 请求 DHCP 时发送的主机名 (Hostname)：在 常规设置 选项卡下填写抓包获取的 Option 12。
    • 请求 DHCP 时要发送的供应商类别 (Vendor Class): 在 高级设置 选项卡下填写抓包获取的 Option 60。
    • 使用默认网关：在 高级设置 选项卡中，建议取消勾选“使用默认网关”。因为本文的 OpenWrt 是作为专门处理 IPTV 的旁路由运行，rtp2httpd 可以在自己的配置里直接指定拉取组播流的上行接口，不需要依赖全局默认路由。如果强行勾选，反而会让系统产生无谓的默认路由指向 IPoE 接口。（注：若你后续还需要通过该接口拉取单播流，建议单独为其手动编写精准的静态路由下一跳，而不是依赖默认网关。）

  4. 补充配置旁路由联网： 为了让这个专门用于 IPTV 的旁路由能够正常连接互联网（方便后续在线安装 opkg 软件包、自动更新 EPG 节目单订阅等），我们需要在其 LAN 口设置 中，将IPv4 网关指向你家中真正负责上网的主路由器 IP，并配置好 DNS 服务器。

设置完成后，重启该网络接口。如果配置无误且鉴权通过，该接口就能成功获取到由电信 IPoE 下发的内网 IP 地址（例如 10.x.x.x）。

6. 配置 rtp2httpd 与订阅地址

网络打通后，我们在 OpenWrt 的 LuCI 界面（服务 -> rtp2httpd）中进行基础配置：

  • 选择对应的上游接口（即刚才获取到 10.x 段 IP 的 IPTV 接口）。
  • 配置本地监听的端口（例如 5140）。

有了服务端，接下来需要有节目源。推荐使用开源项目 Zhejiang_Telecom_IPTV 整理好的频道列表。

为了方便终端使用，可以采用该项目提供的订阅链接形式。将下面的 IP 和端口替换为你 OpenWrt 自己的内网 IP 及 rtp2httpd 监听的端口：

1

https://myepg.org/Zhejiang_Telecom_IPTV/Subscribe/?ip=172.20.10.15:5140

(注：这里 172.20.10.15:5140 是我的 OpenWrt 局域网地址和 rtp2httpd 的监听端口)

最终结果展示

全部配置完毕后，就可以在局域网内任意终端进行观看了：

  • Apple TV / iOS：下载 APTV 或其他直播源播放器，添加上述的订阅链接即可加载完整的浙江电信频道列表（自带节目预告和台标）。
  • 网页测试：rtp2httpd 插件本身十分强大，自带了 Web 版本的视频观看控制台。在配置好后，直接进入 OpenWrt 上的 rtp2httpd 页面，点击流媒体源即可在浏览器内直接无缝播放测试。

通过这种方式，家里再也不用专门拖一根网线接机顶盒，客厅的 Apple TV 完美兼顾了流媒体与本地电视直播的功能。

IGMP 配置与踩坑记录

在整个 IPTV 内网融合的过程中，组播（Multicast）和 IGMP（Internet Group Management Protocol）往往是最容易让人踩坑的地方。这里记录一下我的实际测试结果与遇到的问题：

1. 关于 IGMP 的作用与必要性 IGMP 的核心作用之一是防止组播泛洪（即交换机把组播流当做广播一样，发送给局域网内的所有设备，导致网络拥堵）。 但在我们的方案中，因为已经使用了 VLAN 进行了精细的区域物理隔离，IPTV 的信号已经被严格限制在了专属的 VLAN 内。因此，在这条链路上是否配置复杂的 IGMP Proxy 或 IGMP Snooping，其实对防泛洪并没有太大实质性影响。

2. 核心大坑：水星 SG105 Pro 交换机 如果你和我一样使用的是水星 SG105 Pro 这款轻量级网管交换机，一定要关闭“IGMP 监听 (IGMP Snooping)”功能！ 开启该选项后会导致 OpenWrt 完全无法拉取到组播流。原因可能是该型号交换机的 IGMP Snooping 逻辑设计问题（或许是因为我的 IPTV 并没有接在其定义的“上联口”上导致组播按口修剪错误），总之将其关闭后即恢复正常。

3. 对拉流无影响的设置项 经过实测，以下几处容易被误解的设置其实完全不需要开启：

  • ESXi 端口组安全策略：虚拟机端口组的“混杂模式”、“MAC 地址更改”、“伪传输”均无需接受，保持系统默认的“拒绝”即可，完全不影响拉流。
  • OpenWrt IGMP 版本强制：在 OpenWrt 的 IPTV 接口高级设置中，无论是强制指定使用 IGMPv2 还是 IGMPv3，对实际的拉流均没有影响。

附加技巧：如何验证 OpenWrt 成功收到了组播流？

在 OpenWrt 环境下排查问题时，图形界面的信息往往不够直观。我们可以通过强大的 socat 命令行工具来手动模拟拉流并打印二进制数据包，从而验证网络链路是否彻底打通。

在 OpenWrt 的 SSH 终端中执行以下命令（以组播地址 233.50.201.119:5140 和物理接口 eth1 为例）：

1

socat -u UDP4-RECVFROM:5140,ip-add-membership=233.50.201.119:eth1 STDOUT | hexdump -C

命令原理解析：

  • socat -u：表示单向数据传输（从左至右）。
  • UDP4-RECVFROM:5140：在本地监听 UDP 端口 5140接收数据。
  • ip-add-membership=233.50.201.119:eth1：这是非常关键的一步！它向网络中主动发送 IGMP JOIN 报文，告诉上游设备“请把 233.50.201.119 这个组播组的数据发给我的 eth1 接口”。注意：这里的 eth1 必须替换为你实际 IPTV 的物理网卡名称。
  • STDOUT | hexdump -C：将接收到的 UDP 数据流（本质上是连续的 RTP/MPEG-TS 视频帧二进制数据）导入标准输出，并通过 hexdump 工具以十六进制字符格式（带 ASCII 转换）直观地打印在屏幕上。

如果在执行该命令后，你的终端开始连续不断地疯狂滚动十六进制的字符流，就说明你的底层网络、VLAN 和路由已经完美打通，成功接收到了视频流！接下来只要交给 rtp2httpd 愉快地转换即可。

参考资料