Как решить проблемы роутинга в сети WireGuard “узел-узел”

Я настроил сеть “сайта на сайт” с использованием WireGuard:

wg-server <-сеть A-> маршрутизатор A <--интернет--> маршрутизатор B <-сеть B-> wg-клиент И хост B1, B2 и т.д.

wg-server выполняет некоторые сетевые службы, такие как http, ssh и т.д.

Цель состоит в том, чтобы получить доступ к службам на wg-server с хоста B1.

Соединение WireGuard между wg-клиентом и wg-server работает: я могу получать доступ к хостам друг с другом. Я также могу достичь маршрутизатора A с wg-клиента, но не с хоста B1.

root@wg-client:~# traceroute 192.168.179.1
traceroute to 192.168.179.1 (192.168.179.1), максимальный 30 переходов, 60 байт пакеты
 1  10.8.0.1 (10.8.0.1)  22.939 мс  31.863 мс  32.336 мс
 2  192.168.179.1 (192.168.179.1)  32.235 мс  35.028 мс  34.811 мс

root@wg-client:~# ping -c1 192.168.179.51
PING 192.168.179.51 (192.168.179.51) 56(84) байт данных.
64 байт от 192.168.179.51: icmp_seq=1 ttl=64 время=22.3 мс

[host B1]C:\>tracert 192.168.179.1
Проверка маршрута к 192.168.179.1 через максимальные 30 переходов
  1     4 мс     2 мс     2 мс  fritz.box [192.168.76.1]
  2     5 мс     5 мс     4 мс  wg-client [192.168.76.30]
  3     *        *        *     Превышено время ожидания запроса.

[host B1]C:\>tracert 192.168.179.51
Проверка маршрута к 192.168.179.51 через максимальные 30 переходов
  1    91 мс     2 мс     2 мс  fritz.box [192.168.76.1]
  2     3 мс     4 мс     3 мс  wg-client [192.168.76.30]
  3     *        *        *     Превышено время ожидания запроса.

[host B1]C:\>ping 192.168.179.51
Ping выполняется для 192.168.179.51 с 32 байтами данных:
Превышено время ожидания запроса.

Я также не могу достичь маршрутизатора B или хоста B1 с wg-server.

==> У вас есть какие-нибудь подсказки по анализу и решению проблемы?

Настройка сети:

сеть A = 192.168.179.0/24
сеть B = 192.168.76.0/24

wg-server:
linux armbian
192.168.179.51 eth0
10.8.0.1 wg0

wg-client:
linux raspbian
192.168.76.30 eth0
10.8.0.3 wg1

маршрутизатор A (fritzbox):
динамический публичный ip
внутренний ip 192.168.179.1
маршрутизация 192.168.76.0/24 на 192.168.179.51

маршрутизатор B (fritzbox):
динамический публичный ip
внутренний ip 192.168.76.1
маршрутизация 192.168.179.0/24 на 192.168.76.30

хост B1:
Windows 11
192.168.76.44

Таблица маршрутизации на wg-клиенте:

root@wg-client:~# ip route
default via 192.168.76.1 dev eth0 src 192.168.76.30 metric 202
10.8.0.0/24 dev wg1 proto kernel scope link src 10.8.0.3
[...]
192.168.76.0/24 dev eth0 proto dhcp scope link src 192.168.76.30 metric 202
192.168.179.0/24 dev wg1 scope link

Таблица маршрутизации на wg-server:

root@wg-server:~# ip route

default via 192.168.179.1 dev eth0 proto dhcp metric 100
10.8.0.0/24 dev wg0 proto kernel scope link src 10.8.0.1
169.254.0.0/16 dev wg0 scope link metric 1000
[...]
192.168.76.0/24 dev wg0 scope link
192.168.179.0/24 dev eth0 proto kernel scope link src 192.168.179.51 metric 100

[...] не показаны маршруты к внутренним сетям docker.

Брандмауэр / iptables на wg-клиенте отключен. Перенаправление ip активно:

root@wg-client:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

wg конфигурация на wg-клиенте:

[Interface]
PrivateKey = secret
Address = 10.8.0.3/24
[Peer]
PublicKey = secret
PresharedKey = secret
AllowedIPs = 10.8.0.0/24, 192.168.179.0/24, fd58:8e5e:1d78::0/64
Endpoint = secret.ddnss.de:51820
PersistentKeepalive = 25

wg конфигурация на wg-server:

[Interface]
Address = 10.8.0.1/24
Address = fd58:8e5e:1d78::1/64
PostUp = ufw route allow in on wg0 out on eth0
PostUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PreDown = ufw route delete allow in on wg0 out on eth0
PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 51820
PrivateKey = secret

[Peer]
PublicKey = secret
PresharedKey = secret
AllowedIPs = 10.8.0.0/24, 192.168.76.0/24, fd58:8e5e:1d78::0/64

Редактирование 1:

[host B1]C:\>tracert 192.168.179.1

root@wg-client:~# tcpdump -n -i wg1 icmp
tcpdump: подавленный подробный вывод, используйте -v[v]... для полного декодирования протокола
прослушивание на wg1, тип соединения RAW (Raw IP), длина снимка 262144 байт

==> нет результата на wg1

root@wg-client:~# tcpdump -n -i eth0 icmp
tcpdump: подавленный подробный вывод, используйте -v[v]... для полного декодирования протокола
прослушивание на eth0, тип соединения EN10MB (Ethernet), длина снимка 262144 байт
15:45:47.312930 IP 192.168.76.44 > 192.168.179.1: ICMP echo request, id 1, seq 239, length 72
15:45:47.313068 IP 192.168.76.30 > 192.168.76.44: ICMP time exceeded in-transit, length 100
15:45:47.319822 IP 192.168.76.44 > 192.168.179.1: ICMP echo request, id 1, seq 240, length 72
15:45:47.319906 IP 192.168.76.30 > 192.168.76.44: ICMP time exceeded in-transit, length 100
15:45:47.327341 IP 192.168.76.44 > 192.168.179.1: ICMP echo request, id 1, seq 241, length 72
15:45:47.327396 IP 192.168.76.30 > 192.168.76.44: ICMP time exceeded in-transit, length 100
15:45:48.354899 IP 192.168.76.44 > 192.168.179.1: ICMP echo request, id 1, seq 242, length 72

==> icmp пакеты видны на eth0

==> похоже, что маршрутизации между eth0 и wg1 нет

Решено:

Я решил свою проблему, активировав nftables на wg-клиенте. Теперь трафик маршрутизируется внутри wg-клиента и из сети B в сеть A через WireGuard.

На самом деле это не было окончательным решением. Проблема заключалась в том, что Docker инициирует политику iptables, которая отбрасывает каждый пакет в цепочке пересылки, описанной в https://docs.docker.com/network/iptables/#docker-on-a-router.
Поэтому на wg-клиенте мне пришлось установить два правила и сохранить их:

iptables -I DOCKER-USER -i wg1 -o eth0 -j ACCEPT
iptables -I DOCKER-USER -i eth0 -o wg1 -j ACCEPT

Хост 192.168.76.44 и подобные ему должны иметь маршрут на себе, который маршрутизирует трафик для 10.8.0.0/24 (либо просто 10.8.0.1 в вашем случае) через 192.168.76.30. Без такого маршрута они будут маршрутизировать трафик через свой шлюз по умолчанию (т.е. 192.168.76.1 / маршрутизатор B), который перенаправит трафик на свой WAN (его брандмауэр может отбросить их, потому что IP также принадлежит частному блоку).

Альтернативы добавлению требуемого маршрута на каждом из локальных хостов (которые хотят подключиться к сети / серверу WG) — это добавить маршрут на маршрутизатор B вместо этого или настроить SNAT (маскарадинг IP) на WG-клиенте для трафика с исходным IP внутри 10.8.0.0/24 / в виде 10.8.0.1 (который направлен на 192.168.76.0/24), что делает трафик выглядящим так, будто он исходит с самого клиента (т.е. с измененным / «переведенным» исходным IP на 192.168.76.30). Тем не менее, «решения» могут иметь подводные камни в определенных обстоятельствах.