无论什么防火墙
default deny + 按需 ACL
绝不多配就行了。

@mouyase
ikuai 我不清楚没用过，openwrt 应该问题不大。
核心是依赖 OSPFv2 以及 policy routing （直观点说就是 linux 下 ip rule 那个东西）

@yyysuo
👍千人千面，只要你个人觉得满足需求的就是好方案。就跟有人喜好 fakeip 一把梭，有人痛恨 fakeip 从而对我开发的方案欣喜若狂一样。

但我无法接受 fakeip 所以可能不会尝试，其他方面的配置思路是和你一样的：预定义域名列表内的域名走国内外分流，未知域名通过多次 DNS 回退查询选择更合适的响应。

@mouyase
哥们。。你是来分享方案的，对于别人指出的一些问题要正视。我和#51 都是认可 fakeip 的优点，不接受缺点，所以最终不采用 fakeip 方案。在这一点上，你也没必要按着别人头非要按你方案来吧。。
既然如此，来，这是我自用的方案，比你这个更胜一筹，全真 IP ，内网设备无需任何配置，自动容灾，单臂旁路由随便插拔不残留任何污染，你接受下？
https://github.com/povsister/v2ray-core

@yyysuo
体验上来说确实，省掉 DNS 一个 RTT 的体验是非常好的，还可以直接跳过 DNS 分流这种麻烦的步骤。
而且我提个你们可能都忽视的点，FakeIP 可以非常完美的应对“多个域名套同一个 CDN IP ，但是要针对不同域名走不同代理出口”这样的 case ，全真 IP+不嗅探流量的情况下，刚提到的 case 按域名精准分流是不可能解决的。何况后面 ECH 一普及，你想嗅探都没门咯。

@mouyase
不管黑白，fakeip 总要污染一边，你只能说两害相权取其轻。但结果都是一样的，你选一边牺牲掉吧。
何况，这个黑白名单也不是 100%准确的，github 这种灰色的你到底怎么算，只能两边都牺牲掉。

@yyysuo
扶墙 != 无法直连访问

例如 Github 这种只是被劣化+间歇性 SNI 阻断，所以扶墙是为了改善体验。
Fakeip 要配合 FakeDNS ，DNS 自带不可控 cache ，很容易被各种奇怪的客户端软件缓存解析结果。
而且，扶墙梯重启的时候，不一定会保存之前的域名-IP 映射关系，那之前被客户端缓存的 IP 在重启后的梯子看来就是无效的。
综上，fakeip 问题很多，虽然其大幅度降低了拓扑配置门槛，也省掉了一个 DNS RTT （可以直接将域名送往远程服务器落地再解析），但我个人也拒绝 fakeip 的方案。

@life90
你需要了解 ft 的本质，它本质上是对已经进入 stateful tracking 的连接 bypass 一些处理流程，并不是“ft 开启后很多规则会失效”。实际上，只要你不过多依赖 mangle 表，ft 其实是非常优秀的 offload 手段。默认开启的话我觉得是没问题的。

我这边电信上行给的很足，按实际签约的 120%容量做的上行流控，做法是使用 interface queueTree ，FT 开启的情况下会 bypass simple queue 和 global queue ，但不会和 interface queue 冲突，所以你只需要在 wan 口开启 interface queue ，类型选 queueTree ，算法 CAKE 然后配置一下 nat=on ，rtt 50ms ，diffsrev4 ，类型 dual srchost ，然后再开一下 ACK filter 就可以了，非常简单好用。

@life90
ipv6 短期内没有支持的打算。
OSPFv2 和 v3 是需要独立运行两个实例的，而且属于不同的 RFC 。要支持的话得我再手写 v3 的库才可以，目前是手搓简单版本 v2 的，等有空开源成单独的 go-ospfd 再考虑 v3 支持。

目前我自己已经把动态规则的时间延长到了 48h ，常态生效条目 1500 条左右。不过这个是可配置条目，你可以根据自己的旁路由配置和主路由配置自行调整。过多的代价基本就是内存占用会高，ros 本身路由查询开销基本可以忽略。

ROS 官方硬件只有在开启 fasttrack 的情况下性能还算不错，但是 ft 和 mangle mark-routing/packet 是冲突的。
家用环境 99.9%情况下不需要 mark-routing ，唯一有点价值的就是 QoS：标记 wan 流量走 QueueTree 。
我玩了一阵子，家用旗舰 RB5009 ，千兆跑 mark packet ，经常 pt 下载时候干满 cpu 。后来索性开摆，下行不做 QoS ，上行只在 wan interface 上挂了个 CAKE 流控，然后一下就好起来了，打游戏满速下载也不跳 ping ，非常省事。

手抖发出去了..
主路由 ros ，然后配置正经的单臂路由用做科学用途。非常不推荐用“同一个网段里有两个网关，部分设备指向另一个网关”这种坑人操作，你会碰到包括但不限于不对称路由，环路等奇怪问题。
正经单臂路由方案，纯网关操作，无 fakeip/fakedns 污染，内网设备不需要任何设置。
https://github.com/povsister/v2ray-core

家里正常铺网络，留个稍微大点的弱电箱。
主路由

楼上说的都很对了，要快要定向直接找 hr 打招呼或者找猎头。自己投不管官网还是内推码其实都是泡池子

老实说每次看到这种，我就想真的想，弄个 daemonset 丢 prod 里，对外暴露 grpc 供平台使用。
然后有问题的话直接从平台上开搞。现在 prod 环境最多也就拿个 shell 看看，还是 pod 里的，还是 non-root 。想摸机器的 shell 门都没有，更不要说上去跑命令抓包下回来分析了

@basncy
我同意#5 的话，sb 看起来很强大但实际上体验上是个半吊子。真要考虑网关方案不如自己手搓 TPROXY+路由表转发。
唉，但不懂点网络知识的根本不适合玩旁路由。而且，一堆乱七八糟的教程确实坑了不少人。

@vfx666
给你推荐下我自用的方案吧，网关 TPROXY 方案，纯粹单臂路由不侵入拓扑，全真 IP 。主路由分流，黑白名单随喜好配置，可以在主路由上一键排除/强制某个内网 IP 直连/代理。
缺点就是，你的 linksys 可能只能当个 AP 用了，这个方案要的这些特性现阶段 linksys 应该无法满足。
https://github.com/povsister/v2ray-core

@vfx666
我细想了想，port forwarding 应该是可以用的，不对称路由影响的应该是 DNAT ，你先试试用端口转发吧。
另外建议别折腾一个子网里两个网关这种模式了，老老实实用单臂路由不好吗

因为路由不对称，普通家用路由器的 tcp 是需要看到双向的数据报文才会被 conn-track 到。
在你的配置下

TCP inbound （发送 SYN ）：WAN 访问 - 主路由(Port forwarding ，可以认为是 DNAT+SNAT)- PS5
TCP outbound （回复 SYN ACK ）：PS5 -(这里就直接当 invalid 丢了)- 旁路由（ SNAT ）- 主路由

旁路由连 TCP SYN 都看不到，你回复一个 SYN ACK 被旁路由的 SNAT netfilter 看到，只会当你设备抽风直接丢包。
sb 看不到是因为报文在协议栈就直接丢了，压根没进入 sb 的处理。

@allen2000
没事，精品网服务都是很到位的。你留一下装维师傅的电话有问题直接找他就行，从 10000 号下去的都是投诉单师傅反倒会不高兴。