我有一个 Linux 服务器,它是一个 OpenVPN 端点,但也托管一个网络服务器。当我的客户端连接到网络服务器的服务器地址时,数据包会在 VPN 之外传输。确实如此,因为 OpenVPN 设置的到服务器的路由比进入 VPN 的默认路由更具体。但我认为这是一个“泄漏”。
因此,我尝试设置与 Wireguard 类似的设置(Wireguard 很棒,但我需要 OpenVPN,因为它需要是 TCP)。
我的设置基于 Wireguard 页面以及其他问题: Prevent Routing Loop with FwMark in Wireguard (向那里举行的讲座致敬!) Routing fwmark to VPN gateway using nftables mark
尽管进行了设置,Wireshark 显示 http/https 请求仍然通过物理接口而不是通过 vpn tun0 接口。当我使用 nft 监视器跟踪查看数据包标记时,似乎元标记已正确设置,并且仅出现适当的数据包(发往/来自端口 1194)。
所以我怀疑这是:
- PBR 规则未按预期工作。
- 数据包标记没有尽早发生。
我尝试更改链以将传出数据包标记为:
- 输入路由钩子输出
- 类型过滤钩输出
- --> 没有更多的运气
这些命令返回以下内容:
- ip rule:
0: from all lookup local
32764: from all lookup main suppress_prefixlength 0
32765: not from all fwmark 0x4 lookup vpn
32766: from all lookup main
32767: from all lookup default
- ip route show table vpn:
default dev tun0 scope link
- ip route:
default via 10.8.0.1 dev tun0 proto static metric 50
default via 192.168.1.1 dev wlp4s0 proto dhcp src 192.168.1.10 metric 600
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2 metric 50
END.POINT.IP.ADDRESS via 192.168.1.1 dev wlp4s0 proto static metric 50
192.168.1.0/24 dev wlp4s0 proto kernel scope link src 192.168.1.10 metric 600
-nft list ruleset:
table inet vpn {
chain premangle {
type filter hook prerouting priority mangle; policy accept;
ip saddr END.POINT.IP.ADDRESS tcp sport 1194 meta nftrace set 1
meta mark set ct mark
}
chain postmangle {
type filter hook postrouting priority mangle; policy accept;
ip daddr END.POINT.IP.ADDRESS tcp dport 1194 meta nftrace set 1
ip daddr END.POINT.IP.ADDRESS tcp dport 1194 meta mark set 0x00000004
meta mark 0x00000004 ct mark set meta mark
}
}
- traceroute -n --fwmark=0x4 END.POINT.IP.ADDRESS
shows it goes via the physical interface out of the vpn (as expected)
- traceroute -n END.POINT.IP.ADDRESS
shows it goes via the physical interface out of the vpn (UNWANTED)
非常感谢您提前!