Wireguard не завершает рукопожатие

У меня две системы Debian GNU / Linux (bullseye / sid), обе работают с защитой от проводов на порту 23456, обе находятся за NAT. Оба работают с версией ядра> 5.6 (с поддержкой Wireguard).

Система A является сервером и динамически обновляет выделенную «запись A» на авторитетном сервере имен для своего интернет-домена с правильным общедоступным IP-адресом своего интернет-маршрутизатора. (Межсетевой экран ZyWALL USG 100) назначается с. Это происходит раз в минуту, но общедоступный IP-адрес на самом деле изменяется только при перезагрузке маршрутизатора / межсетевого экрана, чего практически никогда не происходит.

Система B находится за маршрутизатором B VDSL и действует как клиент для защиты от проводов, указывая на динамически обновляемый «Запись A» и порт 33456. Маршрутизатор B - это VDSL-маршрутизатор потребительского уровня, и он разрешает все в исходящем направлении, отвечает только на входящие.

Маршрутизатор / брандмауэр A (ZyWALL USG 100) настроен на пропуск пакетов UDP через порт 23456 через он и перенаправляет их на сервер A. Вот соответствующий экран конфигурации:

Вот файл конфигурации сервера A Wireguard (ключи в этом фрагменте, несмотря на то, что они действительны, но не настоящие):

[Interface]
Address = 10.31.33.100/24, fc00:31:33::1/64
ListenPort = 23456
PrivateKey = iJE/5Qy4uO55uUQg8nnDKQ/dFT1MEq+tDfFXrGNj3GY=
# PreUp = iptables -t nat -A POSTROUTING -s 10.31.33.0/24  -o enp1s0 -j MASQUERADE; ip6tables -t nat -A POSTROUTING -s fc00:31:33::/64 -o enp1s0 -j MASQUERADE
# PostDown = iptables -t nat -D POSTROUTING -s 10.31.33.0/24  -o enp1s0 -j MASQUERADE; ip6tables -t nat -D POSTROUTING -s fc00:31:33::/64 -o enp1s0 -j MASQUERADE

# Simon
[Peer]
PublicKey = QnkTJ+Qd9G5EybA2lAx2rPNRkxiQl1W6hHeEFWgJ0zc=
AllowedIPs = 10.31.33.211/32, fc00:31:33::3/128

И вот Конфигурация защиты от проводов клиента B (опять же, ключи и домен не настоящие):

[Interface]
PrivateKey = YA9cRlF4DgfUojqz6pK89poB71UFoHPM6pdMQabWf1I=
Address = 10.31.33.211/32

[Peer]
PublicKey = p62kU3HoXLJACI4G+9jg0PyTeKAOFIIcY5eeNy31cVs=
AllowedIPs = 10.31.33.0/24, 172.31.33.0/24
Endpoint = wgsrv.example.com:33456
PersistentKeepalive = 25

Вот грязная диаграмма, изображающая ситуацию:

Client B -> LAN B -> VDSL Router B (NAT) -> the internet -> ZyWALL (NAT) -> LAN A -> Server A

Запуск защиты от проводов в обеих системах не устанавливает соединение VPN. Активировав отладочные сообщения на клиенте и добавив правило LOG в iptables, которое регистрирует пакеты OUTPUT , я получаю много из них:

[414414.454367] IN= OUT=wlp4s0 SRC=10.150.44.32 DST=1.2.3.4 LEN=176 TOS=0x08 PREC=0x80 TTL=64 ID=2797 PROTO=UDP SPT=36883 DPT=33456 LEN=156 
[414419.821744] wireguard: wg0-simon: Handshake for peer 3 (1.2.3.4:33456) did not complete after 5 seconds, retrying (try 2)
[414419.821786] wireguard: wg0-simon: Sending handshake initiation to peer 3 (1.2.3.4:33456)

Я добавил правило LOG iptables на сервер, чтобы диагностировать проблемы конфигурации маршрутизатора.

root@wgserver ~ # iptables -t nat -I INPUT 1 -p udp --dport 23456 -j LOG

Он регистрирует пакеты Wireguard, полученные от клиента (но я не могу сказать, недействительны они или неполные):

[ 1412.380826] IN=enp1s0 OUT= MAC=6c:62:6d:a6:5a:8e:d4:60:e3:e0:23:30:08:00 SRC=37.161.119.20 DST=10.150.44.188 LEN=176 TOS=0x08 PREC=0x00 TTL=48 ID=60479 PROTO=UDP SPT=8567 DPT=23456 LEN=156 
[ 1417.509702] IN=enp1s0 OUT= MAC=6c:62:6d:a6:5a:8e:d4:60:e3:e0:23:30:08:00 SRC=37.161.119.20 DST=10.150.44.188 LEN=176 TOS=0x08 PREC=0x00 TTL=48 ID=61002 PROTO=UDP SPT=8567 DPT=23456 LEN=156 

поэтому я склонен предположить, что маршрутизатор A (ZyWALL USG 100) был правильно настроен, чтобы пакеты приходили в локальную сеть сервера. Чтобы подтвердить это предположение, я даже попытался заменить ZyWALL другим маршрутизатором потребительского уровня и переместить сервер через другое интернет-соединение, но проблема все еще существует, поэтому я уверен, что проблема не в брандмауэре и не в его специфической особенности. подключение к Интернету.

Вот конфигурация сети сервера, на всякий случай:

auto lo
iface lo inet loopback

auto enp1s0
iface enp1s0 inet static
    address 10.150.44.188/24
    gateway 10.150.44.1

Вдобавок ко всему, другие VPN-туннели с защитой от проводов ДЕЙСТВИТЕЛЬНО работают правильно, используя тот же клиент, тот же маршрутизатор VDSL (на стороне клиента), тот же Интернет соединение, аналогичная конфигурация сервера (явно разные ключи и домен), аналогичная конфигурация межсетевого экрана (на стороне сервера, другая модель межсетевого экрана).