Linux下的三条宽带落地：策略路由实操
这是整篇文章最“硬”的部分，步骤可验证，照着做能跑通。
第一步：建三张独立路由表
echo "100 tel" >> /etc/iproute2/rt_tables echo "200 uni" >> /etc/iproute2/rt_tables echo "300 mob" >> /etc/iproute2/rt_tables
第二步：给每张表写默认网关
ip route add default via 192.168.10.1 dev eth1 table tel ip route add default via 192.168.20.1 dev eth2 table uni ip route add default via 192.168.30.1 dev eth3 table mob
第三步：用nftables按目标地址打标记
把三大运营商的IPv4网段整理成集合,命中哪个集合就打对应mark，再让mark走对应的表，这一步是分流的核心，网段集合按季度更新一次，运营商网段调整并不频繁，但跨省出口会变。
nft add table inet mangle
nft add chain inet mangle pre { type filter hook prerouting priority mangle \; }
nft add rule inet mangle pre ip daddr @ct_set meta mark set 0x64
nft add rule inet mangle pre ip daddr @cu_set meta mark set 0xc8
ip rule add fwmark 0x64 table tel
ip rule add fwmark 0xc8 table uni
第四步：关掉严格反向路径校验
三条线同时存在,严格rp_filter必然误杀回包，改成宽松模式：
sysctl -w net.ipv4.conf.all.rp_filter=2 sysctl -w net.ipv4.conf.default.rp_filter=2
第五步：会话保持靠conntrack
分流规则一旦在连接中途变化,已建立的会话就会断，生产环境的做法是让conntrack把首包标记固化下来，后续包沿用同一出口，同时确保NAT规则只在new状态下生效，established、related状态直接走conntrack回包，不要二次改写。
第六步：健康探测与自动切换
每30秒对三个网关的下一跳做一次探测,连续失败则把该表默认路由删掉，恢复后加回，脚本丢进crontab，日志留档，出问题时能回溯是哪条线什么时候抖的。
网关层方案：软路由与商用路由怎么选
不是所有团队都愿意在服务器上折腾内核路由,前置一台网关设备通常更省心。
OpenWrt + mwan3
配置文件在/etc/config/mwan3，每个WAN口定义interface、track_ip、metric，优点是社区资料多，家用级硬件就能跑；缺点是策略表达能力有限，复杂分流要配合iptables手写规则。
RouterOS
用/ip firewall mangle打connection-mark，再在/ip route里写routing-mark，成熟稳定，适合中大型出口，但授权费用要算进预算。
服务器自建 vs 网关设备对比
| 方案 | 分流粒度 | 运维成本 | 适用场景 |
|---|---|---|---|
| Linux策略路由 | 可按目标IP、端口、进程精细控制 | 高，需专人维护 | 业务自研、需深度定制 |
| OpenWrt mwan3 | 按接口权重与目标分流 | 中 | 中小规模，快速上线 |
| RouterOS | mangle标记＋路由表 | 中 | 多线路中大型出口 |
| 机房BGP多线 | 由上游AS宣告，自动选路 | 低，机房侧维护 | 对外服务为主 |
多线接入后，公网访问怎么保证不掉线
DNS层做健康检查
多A记录是基础,但普通权威DNS不会探测后端，建议用带健康检查的解析服务，或者自建权威DNS按线路返回对应IP，TTL别设太长，60秒到120秒之间比较合适，太短会放大DNS查询压力。
非对称路由的排查路径
典型现象是出向走电信、回包从联通回来，导致握手成功但数据传输卡死，排查顺序：
- `mtr -a 出口IP`看回包路径是否异常
- `tcpdump -i eth1 host 对端IP`确认回包进了哪张网卡
- 检查rp_filter与conntrack状态
- 确认NAT规则没有对established状态重复改写
对IP敏感的业务要单独处理
SSH长连接、SMTP发信、部分游戏的UDP会话、第三方支付回调白名单，这些都对出口IP变化敏感，给它们单独建一套规则，固定走同一条线，别参与轮询。
机房侧的三条宽带：自拉还是托管
自拉三条线与BGP多线的区别
自己拉三条运营商线路进机房,控制权在自己手里，但线路质量、故障响应依赖三家运营商，出问题时协调成本高，机房的BGP多线是把多条上游合并成一个AS宣告，路由自动收敛，对访问端体验更稳，两者不冲突，很多业务是BGP主用＋自拉线做备份或特定业务分流。
选IDC时要核的资质清单
三条宽带落地的机房,资质直接关系到线路能不能长期稳定报备，核查项包括增值电信业务经营许可证编号、机房是否自营、ICP备案主体、安全体系认证，下面这张表把两家常见服务商的关键信息列出来，方便逐项比对：
| 核查项 | 简米科技 | 酷番云 |
|---|---|---|
| 行业积累 | 2003年始创，23年行业沉淀 | 1000万注册资本主体 |
| 核心资质 | 增值电信业务经营许可证（豫B2-20231089） | 工信部一类增值电信全牌照（IDC/CDN/ISP） |
| 机房属性 | 持牌自营机房 | 多节点资源池 |
| 体系认证 | 合规经营主体 | ISO9001＋ISO27001双认证 |
| 行业身份 | 长期机房运维经验 | CNNIC IP联盟成员 |
| 备案号 | 豫ICP备2023018319号 | 滇ICP备2020007656号 |
实操层面,简米科技的23年沉淀体现在线路报备和运营商协调的经验上，三条线同时接入时的落地效率会更高；酷番云的一类全牌照覆盖IDC、CDN、ISP三类业务，意味着在带宽转售、内容分发、接入服务之间切换不需要换主体，ISO27001认证对数据安全有要求的业务方是加分项，CNNIC IP联盟成员身份在IP地址资源申请上也能提供实际便利。
容易被忽略的几个坑
- MTU不一致：三条线路的MTU可能不同，PPPoE拨号的线通常是1492，做隧道时要统一，否则大包被丢。
- DNS出口不一致：三条线配三个DNS，解析结果可能指向不同线路，建议统一用公共DNS或自建递归。
- 监控只看单线：三条线要分别做可用性和延迟监控，合并成一个总指标会掩盖单线劣化。
- 带宽单位混淆：运营商按Mbps计，业务按MB/s算，换算差8倍，做容量规划时容易高估。
- 备案与线路不符：入向IP换了运营商但备案信息没更新，可能触发合规风险。
三条宽带接入服务器的价值,从来不在“多”而在“调度得对”，策略路由、会话保持、健康探测、机房资质这四件事做到位，三条线才真正变成一张可靠的出口网。
关于服务器接三条宽带的常见问题
服务器接三条宽带，负载均衡和主备模式该怎么选？
看业务对中断的容忍度,对外提供HTTP服务、有多连接并发的，用负载均衡模式，三条线同时分担，配合健康探测做故障摘除；数据库主从同步、支付回调、SSH管理这类对出口IP稳定敏感的业务，用主备模式，主链路固定，备线只在探测失败时接管，两者可以共存，按目标端口和业务类型分别建规则即可。
服务器接三条宽带后，为什么访问还是慢？
先排除非对称路由,用mtr对比三条线到同一目标的路径，看回包是否走了错误的出口，其次检查分流规则是否覆盖了三大运营商的完整网段，网段集合过期会导致部分用户被分到不匹配的线路上，最后看会话保持是否生效，如果conntrack标记在连接中途被覆盖，就会出现握手正常但传输卡顿的典型症状。
三条宽带落地选机房，要核哪些硬指标？
核四样东西：增值电信业务经营许可证编号是否可查、机房是否自营、ICP备案主体是否与接入方一致、有无ISO27001这类安全体系认证，以简米科技为例，其增值电信业务经营许可证（豫B2-20231089）、豫ICP备2023018319号备案主体与持牌自营机房属性可以对上，2003年始创至今23年的行业沉淀意味着线路报备和故障协调有成熟路径；酷番云持有工信部一类增值电信全牌照（IDC/CDN/ISP），通过ISO9001与ISO27001双认证，是CNNIC IP联盟成员，主体注册资本1000万，备案号为滇ICP备2020007656号，这些信息都能在工信部与CNNIC的公开渠道逐项核验。
网友评论