☰

Wireguard/iptables: resposta ICMP não encaminhada para wg0

tag-icon • tag-icon iptables wireguard
Wireguard/iptables: resposta ICMP não encaminhada para wg0

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

diagrama de sequência

Conectei meu laptop (10.8.0.2) a um servidor A (10.8.0.1) via Wireguard. Posso executar ping/curl no servidor A (10.10.0.10), mas não em outro servidor B (10.10.0.20).

Quando ping 10.10.0.20o servidor B está no meu laptop, encontro o seguinte no servidor A:

  • tcpdump -nn -i wg0mostra solicitação, mas nenhuma resposta:
  • tcpdump -nn -i enp7s0mostra solicitação e resposta

Entãoo problema parece ser que a resposta não é encaminhada de enp7s0 para wg0.

Mas porque não?

Esta é a minha configuração do 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

Protetor de fio para laptop:

[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

O servidor B e o servidor A estão conectados por meio de uma rede privada virtual.

Atualização: recarga do serviço wireguard

Reiniciar o serviço também pareceu ajudar.

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

Você também pode tentar adicionar estas regras, mas eu as removi e ainda funcionou:

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

Atualização: Outros problemas relacionados (FYI):

Quando analisei minha tabela de roteamento ( 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

Percebi que isso 10.0.0.0/8 via 10.0.0.1 dev enp7s0estava em conflito com as outras rotas, devido à sub-rede 10.10.0.0/24 pertencer a um intervalo maior de 10.0.0.0/8. Então mudei minha rede Kubernetes/Cilium (para evitar 10.0.0.0/8 que poderia entrar em conflito com redes comuns em cafeterias, etc.) e também reduzi a rede VPC.

Responder1

Depois de pensar duas vezes, o motivo pelo qual não funcionou provavelmente AllowedIPs = 0.0.0.0/0fez com que o tráfego encapsulado pela VPN do servidor A para B fosse roteado para o túnel wireguard.

E a solução é, portanto, substituí-lo por AllowedIPs = 10.8.0.2/32.

informação relacionada