☰

Wireguard/iptables: ответ ICMP не пересылается в wg0

tag-icon • tag-icon iptables wireguard
Wireguard/iptables: ответ ICMP не пересылается в wg0

Диаграмма сети:Laptop (10.8.0.2) -> (wireguard) -> server A (10.8.0.1, 10.10.0.10) -> server B (10.10.0.20)

Диаграмма последовательности

Я подключил свой ноутбук (10.8.0.2) к серверу A (10.8.0.1) через Wireguard. Я могу пинговать/curl до сервера A (10.10.0.10), но не до другого сервера B (10.10.0.20).

При входе ping 10.10.0.20на сервер B с моего ноутбука я обнаруживаю на сервере A следующее:

  • tcpdump -nn -i wg0показывает запрос, но нет ответа:
  • tcpdump -nn -i enp7s0показывает запрос и ответ

Такпроблема, по-видимому, в том, что ответ не пересылается от enp7s0 к wg0.

Но почему нет?

Вот моя конфигурация iptables:

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o enp7s0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o enp7s0 -j MASQUERADE

Защитная пленка для ноутбука:

[Interface]
PrivateKey = ...
Address = 10.8.0.2/24

[Peer]
PublicKey = ...
AllowedIPs = 10.8.0.0/24,10.10.0.0/24
Endpoint = ...

Защита сервера A:

[Interface]
PrivateKey = 
Address = 10.8.0.1/24
ListenPort = 51820
SaveConfig = true
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o cilium_host -j MASQUERADE
PostUp = iptables -t nat -A POSTROUTING -o enp7s0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o cilium_host -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o enp7s0 -j MASQUERADE

[Peer]
PublicKey = 
AllowedIPs = 10.8.0.2/32

Сервер B и сервер A соединены через виртуальную частную сеть.

Обновление: перезагрузка службы Wireguard

Перезапуск службы тоже, похоже, помог.

systemctl reload [email protected]
systemctl restart [email protected]

Вы также можете попробовать добавить эти правила, но я их удалил, и это все равно заработало:

PostUp = iptables -A FORWARD -o wg0 -j ACCEPT
PostDown = iptables -D FORWARD -o wg0 -j ACCEPT

Обновление: Другие связанные проблемы (к вашему сведению):

Когда я проанализировал свою таблицу маршрутизации ( ip route):

default via 172.31.1.1 dev eth0 
10.0.0.0/24 via 10.0.1.50 dev cilium_host proto kernel src 10.0.1.50 mtu 1400 
10.0.0.0/8 via 10.0.0.1 dev enp7s0 
10.0.0.1 dev enp7s0 scope link 
10.0.1.0/24 via 10.0.1.50 dev cilium_host proto kernel src 10.0.1.50 
10.0.1.50 dev cilium_host proto kernel scope link 
10.0.2.0/24 via 10.0.1.50 dev cilium_host proto kernel src 10.0.1.50 mtu 1400 
10.0.3.0/24 via 10.0.1.50 dev cilium_host proto kernel src 10.0.1.50 mtu 1400 
10.8.0.0/24 dev wg0 proto kernel scope link src 10.8.0.1 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
172.31.1.1 dev eth0 scope link

Я понял, что это 10.0.0.0/8 via 10.0.0.1 dev enp7s0конфликтует с другими маршрутами из-за того, что подсеть 10.10.0.0/24 принадлежит большему диапазону 10.0.0.0/8. Поэтому я переместил свою сеть Kubernetes/Cilium (чтобы избежать 10.0.0.0/8, которая могла бы конфликтовать с обычными сетями в кофейнях и т. д.), а также сузил сеть VPC.

решение1

После некоторых раздумий я пришел к выводу, что это, вероятно, не сработало AllowedIPs = 0.0.0.0/0из-за того, что трафик, инкапсулированный в VPN, от сервера A к серверу B направлялся в туннель Wireguard.

И решение, следовательно, заключается в замене его на AllowedIPs = 10.8.0.2/32.

Связанный контент