Eu tenho uma rede wireguard simples composta por um único "servidor" (o único dispositivo com um endereço IP roteável externamente) e dois clientes. A comunicação entre o servidor e os clientes parece funcionar muito bem: a partir do servidor, posso acessar os clientes usando seus endereços wireguard e posso acessar endereços "atrás" dos clientes. Da mesma forma, dos clientes eu posso acessar o endereço wireguard do servidor.
O que não funciona é a comunicação cliente a cliente. Se de um cliente eu tento para pingoutro cliente usando seu endereço IP wireguard, a pingfalha com:
From 192.168.64.10 icmp_seq=1 Destination Host Unreachable
ping: sendmsg: Destination address required
Além disso, essa pingtentativa não resulta em nenhum tráfego UDP entre o cliente e o servidor.
Eu incluí minha configuração wireguard abaixo.
Nós VPN
Em todos os nós:
net.ipv4.ip_forwardé1- Não há restrições na
FORWARDmesa - Eu não estou usando
wg-quickpara abrir a vpn. Estou usando um script de shell que está incluído na parte inferior deste post.
Servidor
# ip addr show wg0
39: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 192.168.64.1/24 scope global wg0
valid_lft forever preferred_lft forever
# ip route show | grep wg0
10.0.0.0/8 dev wg0 scope link
192.168.1.0/24 dev wg0 scope link
192.168.11.0/24 dev wg0 scope link
192.168.13.0/24 dev wg0 scope link
192.168.64.0/24 dev wg0 proto kernel scope link src 192.168.64.1
[Interface]
PrivateKey = <secret key>
ListenPort = 50001
[Peer]
PublicKey = 1cML7...
AllowedIps = 192.168.1.0/24, 192.168.11.0/24, 192.168.13.0/24, 192.168.64.10/32
PersistentKeepalive = 30
[Peer]
PublicKey = mRjd9...
AllowedIps = 10.0.0.0/8, 192.168.64.11/32
PersistentKeepalive = 30
Cliente 1
# ip addr show wg0
33: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 192.168.64.10/24 scope global wg0
valid_lft forever preferred_lft forever
# ip route | grep wg0
10.0.0.0/8 dev wg0 scope link
192.168.64.0/24 dev wg0 proto kernel scope link src 192.168.64.10
[Interface]
PrivateKey = <secret key>
ListenPort = 50001
[Peer]
PublicKey = 2VtQ/...
Endpoint = wg.example.com:50001
AllowedIps = 0.0.0.0/0, 192.168.64.1/32
PersistentKeepalive = 30
[Peer]
PublicKey = mRjd9...
AllowedIps = 10.0.0.0/8, 192.168.64.11/32
PersistentKeepalive = 30
Cliente 2
# ip addr show wg0
11: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 192.168.64.11/24 scope global wg0
valid_lft forever preferred_lft forever
# ip route show | grep wg0
192.168.1.0/24 dev wg0 scope link
192.168.11.0/24 dev wg0 scope link
192.168.13.0/24 dev wg0 scope link
192.168.64.0/24 dev wg0 proto kernel scope link src 192.168.64.11
[Interface]
PrivateKey = <secret key>
ListenPort = 50001
[Peer]
PublicKey = 2VtQ/...
Endpoint = wg.example.com:50001
AllowedIps = 0.0.0.0/0, 192.168.64.1/32
PersistentKeepalive = 30
[Peer]
PublicKey = 1cML7...
AllowedIps = 192.168.1.0/24, 192.168.11.0/24, 192.168.13.0/24, 192.168.64.10/32
PersistentKeepalive = 30
Script de configuração de interface
A wg0interface nos nós é configurada com o seguinte script:
#!/bin/sh
dev=$1
addr=$2
ip link add $dev type wireguard
ip addr add $addr dev $dev
wg setconf $dev /etc/wireguard/$dev.conf
ip link set $dev up
Vamos acompanhar o que acontece:
mRjd9Endpointdefinição para alcançar o 2º par e como nunca houve tráfego recebido na outra direção (pelo mesmo motivo), nenhum ponto final existe. Isso é diferente para o servidor que ao receber o primeiro pacote do Client1 definirá o endereço de origem do Client1 atual como o endpoint.O mesmo acontece na outra direção de Client2 para Client1 : não há
Endpointdefinição e nenhum tráfego foi recebido para ter um endpoint definido.Portanto, o túnel estando atualmente incompleto, falha. wireguard envia o erro
EDESTADDRREQ/ endereço de destino necessário quando isso acontece. Só porque é mais difícil especificar o que é esse outro lado, não significa que omiti-lo magicamente fará com que funcione.Como ambos são NAT, você obtém os problemas usuais de conectividade NAT entre dois dispositivos NAT.
Para resolver isso você pode:
Use o servidor como um servidor do tipo STUN (talvez até mesmo executando um servidor STUN real, mas fora do túnel) para sincronizar o método para Client1 e Client2 para tentar perfurar UDP com túneis WireGuard, supondo que não haja NATs simétricos ou CG NAT no caminho. Isso está além do escopo desta questão do WireGuard para fazer isso corretamente, mas isso deve ser o que favorecer para evitar a necessidade de servidor para todo o tráfego.
Observe que usar
0.0.0.0/0inAllowedIpsem cada cliente não faz sentido assim que houver dois peers definidos, cada um com valores emAllowedIps.0.0.0.0/0será descartado silenciosamente da rota de criptografia no final e não deve ser usado. Um endereço IP pode resolver (ou seja: ser roteado por criptografia) para exatamente um Peer (ou nenhum), mas nunca mais de um.ou, como parece ter sido planejado no OP, retransmitir o tráfego por meio do servidor que exige definir o servidor como roteador em sua interface wg0 (usada para entrada e saída) e alterar a configuração em Client1 e Client2 . Não há protocolo de "rota de criptografia dinâmica", a alteração deve ser feita manualmente ou com scripts em ambos os clientes (até que apareça algum daemon de roteamento capaz de fazer isso para o WireGuard). Por exemplo (aqui, apenas usar
0.0.0.0/0em vez de declarar explicitamente todas as rotas seria bom, agora há apenas um Peer real):Cliente1
A parte abaixo se torna inútil: Client1 nunca tem Client2 como peer, apenas Server . Mas ainda pode ser mantido na configuração:
Cliente2