@dhuzbb
但看到访问者的真实 IP 是一个很常见的需求，假设你暴露的不是 web 服务而是 ssh 服务，那么为了防爆破肯定要 fail2ban ，那么如果无法看到真实 IP ，确实有诸多不便。。

这也是所有”同网段改网关走旁路由科学“方案的一个无法解决的痛点问题。

首先，rdp 是 L7 协议，运行于 tcp 、udp 之上。
所以，nginx 只有 stream module 可以处理，且一般只能处理 sni 和 ALPN ，rdp 并不运行在标准 TLS 协议下，所以，应该没啥用。

其次，域名，在这个 case 下，只负责解析实际 IP 地址，rdp 客户端会直接使用解析后 ip+3389 端口访问，此访问中，理论不携带任何域名信息。nginx stream module 自然无用。

综上，仅通过不同域名+同一个 IP ，不可能做到根据域名分流至不同 rdp 目标。

提示，研究 RDP gateway ，用于解决你 rdp 分流问题

给提个这种配置下的一个小问题，可以思考一下。

假设在 PVE 上有一个 web 服务，而且此 PVE 中，提供 web 服务的容器或虚拟机的默认网关是旁路由。
此时有需求从外网访问，通过公网 IP 的端口映射，直接访问 PVE 上的 web 服务，而且 web 服务要能看见访问者的真实 IP （而不是主路由的 IP ）
请问，这种情况你的拓扑配置可以支持吗

字节的安全审计可不是吃素的，小心饭碗。
真有需求公司电脑带回家，工作和私人电脑分开。

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