☰

Wireguard/iptables: La respuesta ICMP no se envió al wg0

tag-icon • tag-icon iptables wireguard
Wireguard/iptables: La respuesta ICMP no se envió al wg0

Diagrama de Red:Laptop (10.8.0.2) -> (wireguard) -> server A (10.8.0.1, 10.10.0.10) -> server B (10.10.0.20)

diagrama de secuencia

Conecté mi computadora portátil (10.8.0.2) a un servidor A (10.8.0.1) a través de Wireguard. Puedo hacer ping/curl al servidor A (10.10.0.10), pero no a otro servidor B (10.10.0.20).

Cuando ping 10.10.0.20el servidor B de mi computadora portátil, encuentro lo siguiente en el servidor A:

  • tcpdump -nn -i wg0muestra solicitud, pero no hay respuesta:
  • tcpdump -nn -i enp7s0muestra solicitud y respuesta

Entoncesel problema parece ser que la respuesta no se reenvía desde enp7s0 a wg0.

¿Pero por qué no?

Esta es mi configuración de 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

Protector de cables para computadora portátil:

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

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

Servidor A wireguard:

[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

El servidor B y el servidor A están conectados a través de una red privada virtual.

Actualización: recarga del servicio Wireguard

Reiniciar el servicio también pareció ayudar.

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

También puedes intentar agregar estas reglas, pero las eliminé y aún funcionó:

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

Actualización: Otros problemas relacionados (para su información):

Cuando analicé mi tabla de enrutamiento ( 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

Me di cuenta de que 10.0.0.0/8 via 10.0.0.1 dev enp7s0estaba en conflicto con las otras rutas, debido a que la subred 10.10.0.0/24 pertenecía a un rango mayor 10.0.0.0/8. Así que moví mi red Kubernetes/Cilium (para evitar 10.0.0.0/8 que podría entrar en conflicto con redes comunes en cafeterías, etc.) y también reduje la red VPC.

Respuesta1

Después de pensarlo dos veces, la razón por la que no funcionó probablemente fue AllowedIPs = 0.0.0.0/0que los tráficos encapsulados en VPN del servidor A al B se enrutaron al túnel Wireguard.

Y, por tanto, la solución es sustituirlo por AllowedIPs = 10.8.0.2/32.

información relacionada