Human injection attack

@wwd179
vaultwarden 的客户端本地也会有一份 db ，只不过没网时候没办法和云端同步。不影响使用已有的密码。而且可以离线存储密码等有网络再和服务器同步

省会省，但是和时间比感觉又没省。周末做做得了，平时还是出去吃，不点外卖

@mouyase
要不要黑白名单，想怎么去分流完全取决于你怎么配置。
我只是开发并提供了一套机制。示例配置是 gfw 黑名单走 proxy ，其他域名直连+dns 回退防止 dns 污染。如果想黑名单无条件走海外 DNS+ECS ，自行改下配置即可。

是的，无论黑白，返回均为真实 ip ，是否要连接取决于客户端自己，需要代理访问的真实 IP 会由 DNS Route 机制自动完成透明代理的搭建，真正访问时就是无感通过透明代理访问。

无论什么防火墙
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