电脑 --- 路由器 --- 跳板服务 --- 目标服务器
电脑 IP:10.10.*.*
路由器 Wireguard IP:192.168.69.1
要访问的远程服务器 IP:17.*.*.*
电脑在内网,路由器上配置了 Wireguard ,Wireguard 另一端跳板服务在公网。现在内网的电脑想通过 Wireguard 访问到公网的服务器的 QUIC 协议的服务。
现在情况是,如果不走 Wireguard ,电脑通过路由器是可以正常访问到目标服务的,没有问题。但是配置走了 Wireguard ,就无法正常访问了。
conntrack 和 Wireshark 抓包的结果:
看起来是电脑在发送 QUIC 请求,服务端返回了响应包,但是电脑对收到的每个响应包都会回一个 ICMP Port unreachable 的响应,导致连接立即被中断 DESTROY 。
因为 QUIC 协议是基于 UDP 的,所以我拿 Node.JS 简单写了个测试程序,在服务器上监听 UDP 端口,做一个 echo 服务,电脑上给服务端发 UDP 请求,服务端给返回多个响应包:
服务端:
import dgram from 'node:dgram';
const server = dgram.createSocket('udp4');
server.bind(443);
server.addListener('message', async (msg, rinfo) => {
console.log(`Received ${msg.length} bytes from ${rinfo.address}:${rinfo.port}: ${msg}`);
for (let i = 0; i < 5; ++i) {
// 延迟 1 秒
await new Promise(r => setTimeout(r, 1e3));
server.send(Buffer.concat([msg, Buffer.from(i.toString())]), rinfo.port, rinfo.address, (error, bytes) => {
console.log('send to', rinfo.address, rinfo.port, error, 'bytes', bytes);
});
}
});
客户端:
import dgram from 'node:dgram';
const socket = dgram.createSocket('udp4');
socket.addListener('message', (msg, rinfo) => {
console.log(`Received ${msg.length} bytes from ${rinfo.address}:${rinfo.port}: ${msg}`);
});
socket.send("asd", 443, " [脱敏,远端 IP ] ");
结果是正常的,电脑上运行客户端代码,会用一个随机端口给服务器的 443 发请求,服务端收到的包显示远端 IP 是 Wireguard 远端的 IP ,表示数据包确实是走 Wireguard 转发到服务端的,然后服务端回复给 Wireguard 远端的 5 个包也都能正常被内网的电脑收到。
目前没有其他头绪了,来求助问一下,还有什么方向可以排查的吗?可能是什么问题呢?
1
cnbatch 69 天前
可能是 WireGuard 的 MTU 值不够小
|
2
RobinHuuu 69 天前 via Android
使用 ping 排查 mtu 问题
|
3
pagxir 69 天前 via Android
如果全部遵守规范的话,那就只可能是 17 的那个机器没有 quic 服务,或者没在这个 IP 上运行 quic 服务,或者是防火墙不允许。
|
4
qilme 69 天前 via Android
是否有哪个环节用了 http/socks5 代理,这两个不支持 quic
|
5
jinliming2 OP @cnbatch @RobinHuuu 经过排查,不是 MTU 的问题,但是感谢提供 ping 的思路,通过 ping 发现具体的问题了。
通过 ping ,发现只有 icmp_seq 序号为偶数( 0 、2 、4……)的 ping 包才能收到响应,而奇数的包都是超时。就去排查 nftables 规则,发现问题所在: 我给指定服务器做转发,是在 nat 的 prerouting 链上判断目标地址为 17 服务器的包打上 meta mark ,然后在 ip rule 里匹配 fwmark lookup 表,default 路由到 Wireguard 的 wg0 出口。 看了下文档,nat 链只在第一个包会命中,后续包就跳过了。因为有 conntrack 跟踪数据包信息,所以 UDP 包也是只在第一个包会命中,后续包不会命中,导致只有第一个握手包发给了 Wireguard ,后续包都从物理网卡直接出去了,导致了 conntrack 同一个内网 IP + 端口对应不同的出口,触发了 conntrack 的 destroy ,所以服务端响应的包就找不到 NAT 回复的目标了。 我自己写的 UDP 测试程序之所以没问题,是因为每次电脑端每次发送都是用的随机 UDP 端口发一个包,conntrack 只跟踪第一个包,所以正常。如果给客户端代码也加上 bind ,使用相同端口来请求,就会发现和 ping 一样的,一次通,一次不通,分别是 conntrack 的 NEW 和 DESTROY 。 解法是在 meta mark set 的同时加上 ct mark set meta mark 给 conntrack 也打上标记,然后加了个 filter prerouting 的 mangle 链,匹配 ct mark 也设置上 meta mark set 就好了。 |