到目前为止,我在一个服务器(启用NAT )和一个客户机(ubuntu)上设置了wireguard。当我不通过隧道运输所有的车辆时,一切都正常。当我开始通过隧道路由所有流量(如https://www.wireguard.com/netns/#improved-rule-based-routing中所描述的)--不再可能有流量--时,我甚至不能从客户端平服务器的内部隧道地址。
服务器上的路由显然有效。而且,在客户端,流量似乎被正确地路由。来自客户端的数据包出现在服务器的wireguard中,但是来自服务器的数据包没有出现在客户端的wireguard网络中。在客户机和服务器之间的物理链接上,udb通信是双向发生的。
我还在一个运行良好的Android设备上安装了一个客户端。所有的交通都经过钢索隧道。所以对我的ubuntu客户来说肯定是个问题。
我到目前为止所作的所有有关资料和分析如下。
我很少做tcpdump的调查。因此,我经常从客户端点击以下三个地址: 8.8.8.8、192.168.137.1 ( wireguard中的服务器)和aaa.bbb.cc.dd (现实世界中的服务器)。
东道主如下:
192.168.1.103/24
中的客户端192.168.137.23/24
192.168.138.1/24
aaa.bbb.ccc.dd
服务器上的wireguard接口上的TCPDump:
11:25:18.141089 IP 192.168.137.23 > 192.168.137.1: ICMP echo request, id 7162, seq 4997, length 64
11:25:18.141120 IP 192.168.137.1 > 192.168.137.23: ICMP echo reply, id 7162, seq 4997, length 64
11:25:18.654894 IP 192.168.137.23 > aaa.bbb.cc.dd: ICMP echo request, id 8772, seq 2625, length 64
11:25:18.654917 IP aaa.bbb.cc.dd > 192.168.137.23: ICMP echo reply, id 8772, seq 2625, length 64
11:25:18.654928 IP 192.168.137.23 > 8.8.8.8: ICMP echo request, id 7116, seq 5023, length 64
11:25:18.658361 IP 8.8.8.8 > 192.168.137.23: ICMP echo reply, id 7116, seq 5023, length 64
11:25:19.163161 IP 192.168.137.23 > 192.168.137.1: ICMP echo request, id 7162, seq 4998, length 64
11:25:19.163197 IP 192.168.137.1 > 192.168.137.23: ICMP echo reply, id 7162, seq 4998, length 64
11:25:19.677354 IP 192.168.137.23 > aaa.bbb.cc.dd: ICMP echo request, id 8772, seq 2626, length 64
11:25:19.677382 IP aaa.bbb.cc.dd > 192.168.137.23: ICMP echo reply, id 8772, seq 2626, length 64
11:25:19.677393 IP 192.168.137.23 > 8.8.8.8: ICMP echo request, id 7116, seq 5024, length 64
11:25:19.680897 IP 8.8.8.8 > 192.168.137.23: ICMP echo reply, id 7116, seq 5024, length 64
11:25:20.185851 IP 192.168.137.23 > 192.168.137.1: ICMP echo request, id 7162, seq 4999, length 64
回显请求进来,并得到适当的答复。
现在在客户端的wireguard接口上:
10:48:33.129645 IP 192.168.137.23 > 192.168.137.1: ICMP echo request, id 7162, seq 2799, length 64
10:48:33.961380 IP 192.168.137.23 > 8.8.8.8: ICMP echo request, id 7116, seq 2825, length 64
10:48:33.961393 IP 192.168.137.23 > aaa.bbb.cc.dd: ICMP echo request, id 8772, seq 427, length 64
10:48:34.153335 IP 192.168.137.23 > 192.168.137.1: ICMP echo request, id 7162, seq 2800, length 64
10:48:34.985387 IP 192.168.137.23 > aaa.bbb.cc.dd: ICMP echo request, id 8772, seq 428, length 64
10:48:34.985434 IP 192.168.137.23 > 8.8.8.8: ICMP echo request, id 7116, seq 2826, length 64
10:48:35.177511 IP 192.168.137.23 > 192.168.137.1: ICMP echo request, id 7162, seq 2801, length 64
10:48:36.009515 IP 192.168.137.23 > 8.8.8.8: ICMP echo request, id 7116, seq 2827, length 64
10:48:36.009539 IP 192.168.137.23 > aaa.bbb.cc.dd: ICMP echo request, id 8772, seq 429, length 64
10:48:36.201508 IP 192.168.137.23 > 192.168.137.1: ICMP echo request, id 7162, seq 2802, length 64
10:48:37.033320 IP 192.168.137.23 > aaa.bbb.cc.dd: ICMP echo request, id 8772, seq 430, length 64
10:48:37.033360 IP 192.168.137.23 > 8.8.8.8: ICMP echo request, id 7116, seq 2828, length 64
只有回显请求,没有答复:(
现在,客户端物理接口上的udp通信:
10:50:12.265631 IP 192.168.1.103.52635 > aaa.bbb.cc.dd.51820: UDP, length 148
10:50:12.294673 IP aaa.bbb.cc.dd.51820 > 192.168.1.103.52635: UDP, length 92
10:50:17.385691 IP 192.168.1.103.52635 > aaa.bbb.cc.dd.51820: UDP, length 148
10:50:17.422843 IP aaa.bbb.cc.dd.51820 > 192.168.1.103.52635: UDP, length 92
10:50:22.441620 IP 192.168.1.103.52635 > aaa.bbb.cc.dd.51820: UDP, length 148
10:50:22.472414 IP aaa.bbb.cc.dd.51820 > 192.168.1.103.52635: UDP, length 92
10:50:27.625664 IP 192.168.1.103.52635 > aaa.bbb.cc.dd.51820: UDP, length 148
10:50:27.748373 IP aaa.bbb.cc.dd.51820 > 192.168.1.103.52635: UDP, length 92
10:50:32.745569 IP 192.168.1.103.52635 > aaa.bbb.cc.dd.51820: UDP, length 148
因此,数据包从和到有线服务器。
客户端上的wireguard配置:
root@kaksi:~# wg
interface: wireguard
public key: eJIcjMR6/M73mPI8AvvzAr9hV2qFarMwXEWDiOH+Pzk=
private key: (hidden)
listening port: 52635
fwmark: 0x926
peer: 0bseDMk5UFx+j+6Zk8FDYv4OXakOIfZj7UTdMQPtsXM=
endpoint: aaa.bbb.cc.dd:51820
allowed ips: 0.0.0.0/0
latest handshake: 6 minutes, 34 seconds ago
transfer: 134.99 KiB received, 322.50 KiB sent
服务器上的wireguard配置:
interface: wg0
public key: 0bseDMk5UFx+j+6Zk8FDYv4OXakOIfZj7UTdMQPtsXM=
private key: (hidden)
listening port: 51820
peer: eJIcjMR6/M73mPI8AvvzAr9hV2qFarMwXEWDiOH+Pzk=
endpoint: <client's-global-ip>:52635
allowed ips: 192.168.137.0/24
latest handshake: 49 seconds ago
transfer: 781.02 KiB received, 791.92 KiB sent
客户端的路由:
root@kaksi:~# ip route show table all
default dev wireguard table 2468 scope link
default via 192.168.1.254 dev wlp58s0 proto dhcp metric 600
169.254.0.0/16 dev wlp58s0 scope link metric 1000
192.168.1.0/24 dev wlp58s0 proto kernel scope link src 192.168.1.103 metric 600
192.168.137.0/24 dev wireguard proto kernel scope link src 192.168.137.23 metric 50
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 192.168.1.0 dev wlp58s0 table local proto kernel scope link src 192.168.1.103
local 192.168.1.103 dev wlp58s0 table local proto kernel scope host src 192.168.1.103
broadcast 192.168.1.255 dev wlp58s0 table local proto kernel scope link src 192.168.1.103
broadcast 192.168.137.0 dev wireguard table local proto kernel scope link src 192.168.137.23
local 192.168.137.23 dev wireguard table local proto kernel scope host src 192.168.137.23
broadcast 192.168.137.255 dev wireguard table local proto kernel scope link src 192.168.137.23
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev wlp58s0 proto kernel metric 600 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fe80::b6ac:1f:5294:7a4b dev wlp58s0 table local proto kernel metric 0 pref medium
ff00::/8 dev wireguard table local metric 256 pref medium
ff00::/8 dev wlp58s0 table local metric 256 pref medium
客户端上的路由表规则:
root@kaksi:~# ip rule show all
0: from all lookup local
32764: from all lookup main suppress_prefixlength 0
32765: not from all fwmark 0x926 lookup 2468
32766: from all lookup main
32767: from all lookup default
在这两台主机上,除了服务器上的nat规则之外,不存在ip表规则。
服务器是一个debian破坏者,带有debian不稳定的有线包(0.0.20190913-1)。
客户端是一个ubuntu18.04,带有ubuntu的有线包(0.0.20190913-1ubuntu1)。
发布于 2021-03-24 14:25:17
我刚刚解决了一个非常相似的问题
iptables -A FORWARD -o wg0 -j ACCEPT
https://serverfault.com/questions/986631
复制相似问题