☰

Wireguard/iptables: ICMP-Antwort nicht an wg0 weitergeleitet

tag-icon • tag-icon iptables wireguard
Wireguard/iptables: ICMP-Antwort nicht an wg0 weitergeleitet

Netzwerkdiagramm:Laptop (10.8.0.2) -> (wireguard) -> server A (10.8.0.1, 10.10.0.10) -> server B (10.10.0.20)

Sequenzdiagramm

Ich habe meinen Laptop (10.8.0.2) über Wireguard mit einem Server A (10.8.0.1) verbunden. Ich kann den Server A (10.10.0.10) pingen/curlen, aber keinen anderen Server B (10.10.0.20).

Wenn ich ping 10.10.0.20von meinem Laptop aus Server B anrufe, finde ich auf Server A folgendes:

  • tcpdump -nn -i wg0zeigt Anfrage, aber keine Antwort:
  • tcpdump -nn -i enp7s0zeigt Anfrage und Antwort

AlsoDas Problem scheint zu sein, dass die Antwort nicht von enp7s0 an wg0 weitergeleitet wird.

Aber warum nicht?

Dies ist meine iptables-Konfiguration:

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

Laptop-Kabelschutz:

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

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

Server 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

Server B und Server A sind über ein virtuelles privates Netzwerk verbunden.

Update: Wireguard-Dienst neu laden

Ein Neustart des Dienstes schien ebenfalls zu helfen.

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

Sie können auch versuchen, diese Regeln hinzuzufügen, aber ich habe sie entfernt und es hat trotzdem funktioniert:

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

Update: Andere damit zusammenhängende Probleme (zu Ihrer Information):

Als ich meine Routing-Tabelle analysierte ( 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

Mir wurde klar, dass dies 10.0.0.0/8 via 10.0.0.1 dev enp7s0mit den anderen Routen in Konflikt geriet, da das Subnetz 10.10.0.0/24 zu einem größeren 10.0.0.0/8-Bereich gehört. Also habe ich mein Kubernetes/Cilium-Netzwerk verschoben (um 10.0.0.0/8 zu vermeiden, das mit gängigen Netzwerken in Cafés usw. in Konflikt geraten könnte) und auch das VPC-Netzwerk eingegrenzt.

Antwort1

Nach kurzem Überlegen war der Grund für das Nichtfunktionieren wahrscheinlich, AllowedIPs = 0.0.0.0/0dass der VPN-gekapselte Datenverkehr von Server A zu B in den Wireguard-Tunnel geleitet wurde.

Die Lösung besteht daher darin, es durch zu ersetzen AllowedIPs = 10.8.0.2/32.

verwandte Informationen