跟风贴自家软路由实现

设计目标

• 为了玩得开心。
• 并不是追求极致性能。实际上用 n100 跑，常年 CPU idle 90%+。
• 模块化，面向数据包和连接，全真 IP
• 结构复杂但是条理清晰，拓展性好。轻松适配各种形式的 VPN。

设计总则

• 基础 OS 使用 Rocky linux 9。为什么使用 RH 系，问就是历史原因。
• 从 DD-WRT 上迁移出来大概是 2016 年，逐步发展成现在的样子。
• 使用 netns 创建各自相对独立的网络命名空间
• 各 netns 分别分配功能、配置 ip，用虚拟网卡、虚拟网桥互联
• 虚拟网卡（直接接入 LAN 的除外）统一分配静态 MAC 地址，由 IP 地址生成。MAC 匹配被大量应用
• 静态路由宣告，因为都在同一台物理设备，直接使用脚本在必要的 netns 内执行 ip route add。
• 总体使用 bash 编写，部分模块使用 c++
  • 最初是感觉容易移植来着
  • 实际上的好处是脚本部分容易修改
  • ~-Golang？是不错，但是咱不熟。-~ 问就是路径依赖
  • 没有 gui，懒得写，也没必要。有一些 cli 工具倒是。
  • 目前使用了 7 个 /24 的 ipv4，及 4 个 /64 的 ipv6，尽管并不是所有的 ip 段都是必须的
  • 其中，IX、TUN 公用一个 /64，因为这些业务都可能直接和外界连接，选择了节约 IP 段
  • LAN 有一个用于 SLAAC 的 /64
  • 另留有一个 /64 用于 LAN 的静态 v6 的 SNPT（历史遗留设计，但是这样比较容易配置 IP）
  • 一个独立的 /64，用于不同于 SLAAC 的 v6 公网地址访问外部时使用（历史遗留设计；实际上可以不使用）

具体实现

• NET-IX，虚拟交换
  • 软路由的核心，使用一段内网 v4（/24），并分配一段内网 ipv6（/68）
  • 提供的主要功能包括，调度（故障自动处理、分流）及服务（DNS，AC，etc）
  • 其中的主要功能模块：
    • INGW，内网接入网关，同时配置 LAN 侧网关 IP
      • 内置各种策略，以针对不同的接入设备应用不同的实际 DNS 等
      • 可以支持基于 IP（v4，v6）地址配置策略，对于直接接入的设备，也可以通过 MAC 地址配置策略
      • 对于来自 VPN 的流量，采用 XC 网段互联，将流量导入到 INGW 应用策略
      • 对于不同的策略，匹配不同的路由表。DNS 服务的 IP 使用 VIP：对于设置需要过墙的设备，转发到 DNSOW；其他转发到 DNSIW
      • 类似的，还可以配置其他策略，如存在 adblock 策略，可配置 DNS 的 VIP 到带广告过滤的 DNS
    • DNSIW，普通 DNS，dnsmasq 转发运营商 DNS
      • 对于多条宽带，手工配置了两个运营商的 DNS
    • DNSOW，过墙 DNS+ 白名单一次筛选，dnsmasq 设置白名单转发前述 DNSIW，其他转发 RECURSIVE
      • 对于需要 DNS 分流的，全部转给 DNSROUTE/ 或者全部转给 DNSROUTE
      • 使用 EDNS 带内网源 IP
    • OWGW，隧道入口，对于白名单内的 IP 转发至 RTGW。更多详情见 TUN 部分。
      • 使用了国内 IP 列表
    • BLACKHOLE，黑洞，吃掉没用的东西并返回 icmp/icmp6
    • RECURSIVE，递归解析，单栈，bind 实现
      • 为什么没用 mosdns？问就是历史路径依赖，做到这个大概是 2018 年
      • 当然，换成其他递归也没问题
    • DNSROUTE，dns 分流 / 策略分流，c++ 自行开发，后续有详细说明
    • RTGW，IX 网段的出口网关，连接到 WAN。详情见 WAN 部分。
  • 其他次要功能模块
    • AC，AC 控制器，用于控制 AP
    • ADBLOCK，去广告 dns，去广告并转发 DNSOW
      • 使用 EDNS 带内网源 IP
  • 基本分流原理：DNS 白名单 +IP 白名单
    • 对于 DNS 白名单内的域名，转发到 DNSIN，本质上是转发 ISP 的解析的。
    • 对于 IP 白名单内的 IP，当然是直接走运营商出口（交给 RTGW）出去
    • 对于 DNS 白名单外的域名，通过 RECURSIVE 解析
    • RECURSIVE 出来的流量会根据 IP 白名单进行分流
    • 因此，（绝大多数情况下）如果解析的是境内网站，那么最后一次查询权威会访问境内的权威服务器，因此他的权威看到的你的地址是宽带出口，会正常返回境内并且合理的 IP 地址。
    • 如果解析的是境外网站，那么最后一次权威查询的是境外服务器，会看到境外出口 IP 的地址，返回正常的境外 IP。
    • 有的境内网站也有境外权威？是的，但是通常境内权威会快得多。对于屡教不改的个别网站（如果有的话），手工补充进 DNS 白名单就是了。
• NET-LAN，普通接入
  • 分配独立的内网 v4（/24）和 v6（/64），使用 dnsmasq 和 radvd 管理
  • 考虑到一些设备需要拿到真实 v6，目前采用实际的 v6 分配，所以每次 v6 地址变化需要更新地址以及相应的路由表
    • 也可以直接分配 fd 开头的 IP，反正可以 SNPT
    • SNPT？nft 您的 cli 支持吗？还是继续用 iptables 吧
  • 无 TAG，直接接交换机，墙上的网口都接入这个网段
  • 通过 INGW 与 NET-IX 互联并实现策略
• NET-WAN，宽带接入
  • 只有链路本地的 v6，使用 fe80::/10 可以转发数据包即可
  • 实现了 PPPoE、DHCP-client 等几个常见的接入，还有独立的 IPTV 接入，通过 udpxy 转发实时节目
    • 因为我拿到运营商送的机顶盒的时候，就已经那样看了好多年了
  • RTGW，连接到 NET-IX
    • 实现了 connmark，用于解决多宽带连入连接的问题
    • 还依赖了 ctdir 来区分连入还是连出连接
    • 对不同的宽带，使用静态路由表 + 子路由表打底默认路由的形式
      • 网速叠加？算了算了。真的用得到极限网速的机会非常少。
      • 而且……这样搞势必跨运营商，效果真的好吗？
      • 真想做的话会考虑在 DNSIW 那里。
  • 对于来自 WAN 侧的数据报文，如果对应的连接没有 connmark，则根据来源 MAC 地址记录 connmark 供后续包使用
  • 对于每条宽带，使用两个 NS，分别是 ISP 和 PROXY：
    • ISP，装有对应的物理网口，设置默认路由为运营商侧
    • ISP 绑定运营商的 v4；对于 v6，这边 pd 到 /60 的段，加黑洞路由，然后将用得到的地址（一个 /62）指向 RTGW
    • ISP 进行 SNAT，对于 v6，进行 SNPT，将内网用到的 v6 地址（包括 LAN 用到的那一段“公网”IPv6 地址）SNPT 成合法的 v6；例如，分配了来自联通宽带的 IPv6 给内网，那么需要从移动出去的时候就会被 SNPT 成移动的 IPv6。
    • 对于 PROXY，包含通往 TUN 网段的虚拟网口，将所有流量都转发给对应的 ISP。用于解决 TUN 中需要指定使用某条线路的问题。这里没有反向路由，反向走普通 RTGW 回去。
    • 如果有一只海外小鸡，这下就可以变成（v4+v6）*（移动 + 联通）一共 4 只了！结合负载均衡或者健康检查一下还能有稳定的出口 IP。
• NET-TUN，模块化连出 VPN
  • 使用一个独立的内网 v4 网段（/24）、一段内网 v6 网段（/68）
  • 额外接入 OWGW、DNSROUTE 连接到 NET-IX，以及 RTGW 连接到 NET-IX 和 NET-WAN；还有接入 PROXY 连接到 NET-WAN 用于线路选择
  • 对于每一条隧道，均包含两个 netns：TN 和 FW
    • 当前的 /24 可以配置 120+ 个隧道，实际上配置了 100 个
    • TN 用于接受转发过来的数据包，通常是 OWGW 或 DNSROUTE 转发过来的，将这个数据包通过各种协议（tproxy，tun，etc）丢进某个隧道或者丢给 FW
    • TN 的默认路由指向 FW 或隧道，视协议而定
    • TN 和 FW 之间现在有独立的一对 veth 互联，各自设置 noprefixroute，未来有将 TN 和 FW 分开到两个不同网段的考虑
    • FW 默认路由指向 RTGW（自动）或某个 PROXY（手工指定出口）
  • 现在的典型配置是，隧道程序在 FW 运行，个别在隧道上运行的 OpenVPN 等放在 TUN
  • VPN 出口调度：
    • 在 OWGW 中操作
    • 使用类似 RTGW 的 connmark 策略调度各连接
    • 对于有 connmark 的数据包，按照 connmark 调度
    • 除了来自 RECURSIVE 的请求，如果没有 connmark，那就请他去 DNSROUTE 走一圈，除非他刚刚从那边来（看来源 MAC）
    • 如果仍然没有 connmark，匹配路由规则，转发给编号最小的有效隧道
      • 在此 NS 中，存在大量的 ip rule 和多张路由表。好在对应每个隧道的 rule 相对简单，就是指向对应的路由表；对应的路由表也简单，就一条，默认指向某 TUN 的 TN
    • 如果收到来自任何隧道的数据包，记录 connmark 供后续使用（还是看来源 MAC）
  • 自动化健康检查
    • 有额外的脚本去不断检测各隧道
    • 对于质量不佳的隧道删除对应的路由规则但是保留路由表
    • 这样后续新建的链接就不再会进入那些隧道了
      • 但是对于已经打 mark 的连接仍然会保持
      • 避免了切换隧道时大量连接断开，特别是在一个优先级高的隧道变成可用时
  • DNSROUTE 目前使用自行开发的 C++ 程序实现：
    • 匹配 DNS 解析请求报文
    • 如果匹配策略，交给对应的 TUN 解析；对于返回的 A/AAAA 记录，记录源目的 ip
      • 这里有个小问题。如果只有部分域名会经过 DNSROUTE 的话，需要拍平 CNAME。或者就让所有域名都经过 DNSROUTE，只需修改 TTL。都实现了，上线的是前者。
    • 对于转发过来的数据报文，使用类似 LVS-DR 的方法，通过 rawsocket 贴上对应的目的 MAC 地址发给对应的隧道
    • 效率？那当然是比较差了，甚至我是没本事把他塞进 ebpf。不过好在 OWGW 只会把每个连接的第一个 / 前几个报文转发过来，因为一旦有来自隧道的报文回到 OWGW，连接就有了 connmark，后续报文就不再依赖 DNSROUTE 了
    • v6 怎么办？凉拌，做映射表，或者在这部分把 v6 关掉。还记得刚才的黑洞吗？OWGW 上把 v6 的默认路由丢进去就没烦恼了
    • 现在已知一个 bug，没能正确处理碎片包，好在几乎没有影响，后续会修改
• NET-XC，内部互联，将连入 VPN 导入 INGW 并应用策略（只能应用三层策略）
• VPN，拨入 VPN，适当实现即可，用 openvpn 或者 wireguard 或者两个都用都没问题
• NET-IoT，物联网，使用 VLAN，在 AP 上开不同的 SSID。
  • 因为只需要访问境内网络所以从 NET-IX 直接接入默认路由指向 RTGW 即可。
  • 这是历史遗留设计。如果现在设计的话也会走 NET-XC 了，能实现但是懒得改。

为什么说玩得开心呢

• 当然是在外边也可以进行很多修改
  • 有了新的小鸡 / 要调整某些隧道，只需新增一个 TUN 配置文件，选一个空着的 TUN ID，放到相应目录里，然后 addtunnel ${TUNID}（cli 工具）就好了。删除的话也只需要 removetunnel ${TUNID}。不会影响整体上网，也不影响其他隧道。
  • 调整健康检查也是。健康检查程序分成两部分，一部分负责检查，将觉得可以用的 TUNID 写到一个目录中；另一个用 inotify 或者什么都好听着那个目录，去操作 OWGW 中对应的规则。显然，前一部分也是可以在外边修改甚至停下来的。
  • 多 WAN 支持，甚至可以在外边改一个暂时不用的 WAN。
  • 只有核心的几个模块是必须在本地改的，好在他们现在也不需要什么改动。
• 还有就是，复杂但是有很大的扩展空间。
  • 在大约 2020 年上线 DNSROUTE，用了源 + 目的双 IP 匹配
  • 后来给每个 TUN 都加了属性，给 DNSROUTE 新增了功能。就是对于来源于某个 IP/CIDR 的，发给带有特定属性的 TUN。
    • 比如我有一只美国小鸡，通过多条 TUN 连接，都含有某个属性
    • 然后可以设置一条规则给 DNSROUTE，让他对来自某个特定 IP 段，比如 192.168.5.0/24 的，转发给这个属性的 TUN
    • 然后我就可以开一个 SSID，比如叫“美国直通车”，通过 vlan 分 192.168.5.0/24 的 IP，手机连上这个 wifi 就可以直通美国了
  • 这么玩还可以隧道串接
    • 比如某个小鸡的出口买了 DNS 解锁
    • 那么就给这个小鸡出口的相关 TUN 都带上某个属性
    • 起一个新的 TUN，叫做“dns 解锁”。其 FW 出口不是通常的指向 RTGW 或者 PROXY，而是指向 OWGW（需要设置 SNAT）
    • 但是同时给 DNSROUTE 设置，来自于这个 IP 的，走某个属性的出口
    • 最后效果就是，即使某条线路不好用了 / 某个宽带断了，只要还能到那个 IP，就能维持解锁