@jtshs256 #3 忘了说了，Mellanox ConnectX-3 洋垃圾（ cx341 ）

@germain #1 iperf3 似乎没有这个问题，我去试试 NTTTCP

这三个设备都不在一个网段，得看路由了吧。

CentOS 升级遭不住，还是 Debian 系好，看清楚升级时的提示基本升不烂吧。

移动的 UDP 质量和劫持问题还是没什么改善，更不要说跨网了。。（虽然说广东移动大概率是因为其他原因导致的跨网困难的）

Openwrt 是一个广泛使用的操作系统，它的稳定性应该不会差到充当家庭路由，都会经常性的出现问题。
毕竟下面的设备，可能用的都是定制的 Openwrt 系统
1.光猫（尤其是 SDN 光猫）
2.CM
3.互联网品牌的路由
4.Pon Sticker/猫棒
5.随身 WIFI

Openwrt 作为一个开源系统，我个人作为有开源癖好的人，自然还是必须要推荐一波的，下面有几点建议希望能够帮助到大家：
1.尽量使用官方兼容的镜像，比如说原版镜像，官方 Image Builder 镜像，自行编译的兼容镜像
2.三方镜像选择开源可自行编译版本，使用自行编译的版本而不是预编译版，有条件可以对比下修改内容
3.对于使用到的插件，尽量避免其包含 1)预编译不开源二进制文件 2)已混淆、加密的代码

其实我优先选择开源软件的一大理由，就是作为最终用户，还是能够有能力自己去调试、解决遇到的问题（ BUG ），修复后还可以贡献给上游。但是对于闭源软件来说，想要自己调试、修复基本上是非常难得，只能依赖于希望提交给官方后，他们能够积极响应修复了。
（毕竟 RouteOS 的 BUG 其实也不少，时常见到有 ROS 用户吐槽）

说点可能会让部分同学不开心的话，但是“旁路由”这个词汇诞生的第一天，就充满着一股“民科”味，比较令人困惑。
一开始说道旁路由，大部分同学的反应可能是“旁路”：就是你们懂得设备，或者安全审计网关常用的“端口镜像”；
后来仔细一看才知道，原来是找了个设备，做了点策略路由，再加了一道 FORWARD 机。

其实总结下来，我个人看法是“又菜又爱玩”

如果非要说就拿大家常用的“你懂得”功能来说：目前大部分的旁路由，高级一点的利用了 DHCP“推送默认路由”等方式，推送默认路由。原始一点的手动修改客户端的默认路由，这其实都是对网络不够了解的提现（为什么说菜就在这里了，同时修改默认网关的操作，也做不到路由炸了自动切换什么的，所以稳定性谈不上优点）。

大家常用的功能，通篇下来就一个词“策略路由”；既然是策略路由了，为啥还需要还分两台路由做呢：
1.主路由性能太菜；
2.主路由是傻瓜路由；
3.主路由系统不支持某些软件运行；（这点还是有限制条件的）
除此之外，我想不到其他太充分的理由，需要利用到第三方的“旁路由”了。

将一个策略路由拆分成两部分，本身就非常割裂，除了物理限制的情况下，其他情况都不应该去这么做，因为收益并不明确，但是副作用却很明显。

就拿大家常说的“修改默认网关来说”，较为一体的解决方案应该是考虑到，新增策略路由做 FORWARD 就可以了，这样整条策略才够完善，对客户端没有影响的同时，规则会非常灵活（配合探活很容易就可以做到策略转移，也就是“稳定性”了）。

那么其实问题就很明显：
1.既然只是一个 FORWARD 的“策略路由”，为什么要上升到“修改默认路由”这一个非常危险的操作呢？
2.如果只是一个 FORWARD 操作，FORWARD 到本机，理论上拥有更低的瓶颈和更高的性能，FORWARD 到外部能提供什么呢？

对于主路由能够支持、且性能没有瓶颈的情况下，旁路由存在的必要真的很不明确。

很多同学可能觉的“插件”之间存在冲突等兼容性问题：那其实在旁路由上，都能做到“手搓”策略的同学，在主路由上肯定也能做到。
我也相信，如果肯花时间“手搓”策略的话，Debug 冲突插件肯定也是必备的技能，毕竟“手搓”的过程中也需要 Debug 。
所以在考虑到这种情况下，相比起来，旁路由也不是一键省事省力省心的事情。

说句题外话，“旁路”本来的意思不是这个意思，“旁路”！=“旁路由”。

这上行太深圳了。

怪事，应该早就有了
https://www.v2ex.com/t/587653#reply121

mark 一下
不过看到“我不是天才型资质，但毕竟也考了 985 ，智商基本够用”后，感觉参考价值可能就不大了。我也达不到 LZ 帖中定义的普通人了。

@titanium98118 #4 那路由端拨号后还能获取到 IPv6 吗？
我这边用的 openwrt 把 IPv6 从自动改手工 /关闭，路由也会直接获取不到 IPv6，昨天查了下看起来像是 pppoe 拨号的时候参数有差别。
但是选择自动的话，就会获取 DHCP-PD，然后下发 IPv6 给客户端，有点头大。

@ihipop #5 是的，我想了半天感觉可能比较好的解法也只有 nat6 了。但是感觉还挺复杂的，头大。

@raysonx #13 噢噢，确实我之前也看到 NPT 这个描述，还没来得及去看，晚点去看一下。
那这个 NPT 的功能，是只能针对一个网段的 1：1 映射吗？还是说能支持 n：1 的（把多个网段，映射到一个内网网段中），如果支持的话感觉就不用倒腾了。
不过还是得找一下 openwrt 有没有这种功能兼容，不然的话可能还是要写脚本自己手撸规则。
或者是写规则重定向给旁路路由，旁路路由再处理这些东西，不知道可不可行。

看了一下大佬的历史帖子，感觉对网络这块很有研究呀。大佬有联系方式吗，想交流（请教）一下））

@billccn #15 其实也不高级，就是个透明代理而已哈哈。不过是底层级别的路由，不是 Clash 那种软件上的路由了，我还在想这个方案怎么实现比较好。


@Rocketer #16 现在的运营商都有成熟的源地址检测的，把一个运营商的 IP 路由到另一个运营商的网关，是通不了的。

现在看来如果客户端有两个 IP，想在路由侧影响源地址选取确实没什么办法。

@pcslide #10 是的，其实不用太纠结“默认的规则可以用”这件事，我想和大家探讨的问题其实是“默认的规则并不合适，要怎么去改变”

@billccn #7 好主意，用 tcp redirec 透明代理特定端口的这个方法我的确忽略了。不过使用这种方法的话，似乎对局域网内所有的机器都是统一规则了，如果要实现类似 mwan 规则的话感觉上可能要比较复杂了。
还有一个问题就是因为 DHCP-PD 是动态的，还要办法监控一下 DHCP，不然 IP 变更后路由表就会出问题。
同时如果局域网内，想设置一个默认出口的 IPv6 似乎也没办法实现（不满足代理规则的情况下，就会控制不到。由于有多个 DHCP-PD 的话，局域网内其他客户端也同时会有多个 IP ）
晚点我看看能不能简单实现下

@cwbsw #8 你可能没有认真看我的帖子，我的诉求就是如 @billccn 所说。现在的问题就是 IP 地址最长匹配选出来的 IPv6，并不是路线优解。
这个问题只能通过手动调整路由表实现，由于我在主楼和 3#所说的“使用的 IP 是由客户端选择的”，但是不能路由 A 运营商的 IP 到 B 运营商的路由，所以单纯修改路由表的方式是不行的，不知道这么说你理解没。

@geekvcn #9 这个也只是网内的情况，考虑更多的是网外的情况，协议默认选择出来的 IP 并不是实际上的最优解。

这次主要是想和大家探讨，怎么去控制 IPv6 的路由走向的方法，而不是“默认已经就有了，不用控制”这个问题。

NAT6 我也说了并不是比较好的解决方法，有一下几个原因
1.很多路由器并不兼容，就算兼容的对于相关工具链也不是很完善（基本上都靠手写规则了）
2.NAT6 的支持大部分止步于对 1 个 IPv6 进行 NAT，而支持 1：1 NAT 的我现在还没找到（本文其实更希望达到的 n：1 效果了）
3.需要为每个 IP 配置 2*n 条以上规则（ n 为出口数目）。出口同时 IP 发生变更时，需要重新生成规则非常麻烦。

@ghjexxka #1 路由不通呀，使用的 IP 是由客户端选择的，如果把 A 运营商的 IP，路由到 B 运营商，这样是不行的。

电费还是蛮吓人的。。

明天去试试，感谢 lz