Wireguard: пакеты, возвращаемые с сервера, отбрасываются

Я уже установил Wireguard на одном сервере (с включенным NAT) и на клиенте (ubuntu). Когда я не маршрутизирую весь трафик через туннель, все работает. Как только я начинаю маршрутизировать весь трафик через туннель, как описано в https://www.wireguard.com/netns/#improved-rule-based-routing , трафик становится невозможным, я даже не могу ping внутренний туннельный адрес сервера от клиента.

Маршрутизация на сервере явно работает. Также на клиенте трафик, кажется, маршрутизируется правильно. Пакеты от клиента появляются в проводной сети сервера, но пакеты от сервера не появляются в сети проводной защиты клиента. По физическому каналу между клиентом и сервером трафик 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

Дамп TCP на сервере через интерфейс защиты от проводов:

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

Входят эхо-запросы, и на них правильно отвечают.

Теперь на клиентском интерфейсе защиты от проводов:

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

Таким образом, пакеты от и к серверу защиты от проводов.

Защита от проводов config на клиенте:

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 

На обоих хостах нет правил таблиц IP, за исключением правило nat на сервере.

Сервер - это debian buster с пакетами wireguard из debian unstable (0.0.20190913-1).

Клиент - это ubuntu 18.04 с пакетами wireguard ubuntu eoan (0.0.20190913-1). 20190913-1ubuntu1).