Eu sou um laber doméstico. Eu tenho uma VPN WireGuard funcionando sem incidentes há cerca de 16 meses. Ele é executado em uma instalação do Ubuntu Server em uma VM. O hipervisor está sendo executado no TrueNAS CORE.
Desde que configurei o WireGuard pela primeira vez, tive um problema em que os clientes não conseguiam se conectar à Internet pública por meio da VPN. Mas como meu objetivo principal ao configurar a VPN era apenas poder gerenciar remotamente meus servidores e acessar dispositivos em minha rede, isso não foi um grande problema. Usei a AllowedIPs
configuração na configuração do cliente para rotear apenas o tráfego para minha 192.168.10.0/24
sub-rede por meio da VPN, e o tráfego destinado à Internet pública não atinge o WireGuard.
Recentemente reiniciei minha VM Ubuntu. Quando ele voltou a ficar on-line, consegui me conectar à VPN WireGuard e, por meio da VPN, posso me conectar a qualquer serviço em execução na minha VM Ubuntu (192.168.10.240). No entanto, não consigo me conectar a nenhum outro dispositivo na minha rede.
Usei curl
no Ubuntu VM e ainda consigo ver outros dispositivos (como TrueNAS Core). Também posso usar um túnel SSH para acessar esses outros dispositivos. Mas não consigo acessá-los via WireGuard como normalmente faria.
A única coisa que estou ciente de que mudou desde a última vez que reiniciei o Ubuntu VM é que instalei o Pterodactyl Wings no Docker. Isso adiciona uma interface Docker Bridge. (Sub-rede 172.19.0.0/16, gateway 172.19.0.1) Mas até onde sei, não há razão para que isso entre em conflito com a rede do WireGuard.
Eu realmente não sei por onde começar a solucionar esse problema e adoraria qualquer conselho que você possa ter.
EDIT: Como você pode ver abaixo, estou usando comandos PostUp/PostDown para garantir que as tabelas IP estejam manipulando corretamente o MASQUERADE. Minha sub-rede WireGuard ( 10.8.0.1/24
) não entra em conflito com mais nada na minha rede. Eu tenho vários pares configurados e cada um tem um único /32
nesta sub-rede. E os AllowedIPs do meu cliente estão configurados para rotear o tráfego para 192.168.10.0/24
.
Enquanto meu cliente está conectado, também consigo executar ping com êxito 10.8.0.2
no servidor e no cliente. Também posso executar ping em um cliente de outro cliente.
Como posso me conectar a 192.168.10.240, isso provavelmente significa que o servidor WireGuard está fornecendo uma rota de 10.8.0.0/24
para 192.168.10.0/24
. Parece que o problema ocorre quando o tráfego precisa sair fisicamente desse host. Então, talvez o problema esteja no meu roteador USG (mas não mudei nada perto do momento em que reiniciei minha VM) ou talvez o Ubuntu não esteja aceitando o tráfego relevante da NIC?
Não sei como solucionar isso.
EDIT2: Conectei fisicamente um dispositivo cliente à rede do meu homelab e ele conseguiu acessar todos os servidores conforme esperado. Mas então ativei o WireGuard (enquanto ainda estava fisicamente conectado) e perdi o acesso a todos os servidores, exceto 192.168.10.240. Portanto, isso indica que o cliente WireGuard está definitivamente roteando o tráfego para esses endereços através do túnel.
Também tentei temporariamente usar uma iptables
configuração bem minimalista (veja abaixo), mas não resultou em nenhuma alteração.
Configuração do servidor WireGuard:
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = [redacted]
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
PublicKey = [redacted]
AllowedIPs = 10.8.0.2/32
Configuração do cliente WireGuard:
[Interface]
PrivateKey = [redacted]
Address = 10.8.0.2/24
[Peer]
PublicKey = [redacted]
AllowedIPs = 10.8.0.1/24, 192.168.10.0/24
Endpoint = example.org:51820
Detalhes da rede:
- Sub-rede 192.168.10.0/24
- Gateway 192.168.10.1 (UniFi USG)
- Faixa DHCP 192.168.10.100 - 192.168.10.199
Anfitriões relevantes:
- Servidor TrueNAS (físico) - 192.168.10.221
- Servidor QuickSync (físico) - 192.168.10.222
- IPMI para TrueNAS (físico) - 192.168.10.231
- Ubuntu VM hospedado no servidor TrueNAS - 192.168.10.240 (servidor WireGuard!)
- Contêiner Docker no servidor QuickSync (macvlan) - 192.168.10.241
Tracert:
C:\Users\test>tracert 192.168.10.221
Tracing route to 192.168.10.221
over a maximum of 30 hops:
1 * 25 ms 20 ms 10.8.0.1
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.
Trace complete.
Ping do servidor para o cliente
PING 10.8.0.2 (10.8.0.2) 56(84) bytes of data.
64 bytes from 10.8.0.2: icmp_seq=1 ttl=128 time=20.4 ms
64 bytes from 10.8.0.2: icmp_seq=2 ttl=128 time=27.0 ms
64 bytes from 10.8.0.2: icmp_seq=3 ttl=128 time=19.4 ms
64 bytes from 10.8.0.2: icmp_seq=4 ttl=128 time=27.1 ms
64 bytes from 10.8.0.2: icmp_seq=5 ttl=128 time=27.2 ms
^C
--- 10.8.0.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 19.409/24.223/27.209/3.536 ms
Ping do cliente para si mesmo (na VPN)
Pinging 10.8.0.2 with 32 bytes of data:
Reply from 10.8.0.2: bytes=32 time<1ms TTL=128
Reply from 10.8.0.2: bytes=32 time<1ms TTL=128
Ping statistics for 10.8.0.2:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Ping de cliente para outro cliente
Pinging 10.8.0.2 with 32 bytes of data:
Reply from 10.8.0.2: bytes=32 time=64ms TTL=127
Reply from 10.8.0.2: bytes=32 time=41ms TTL=127
Reply from 10.8.0.2: bytes=32 time=39ms TTL=127
Ping statistics for 10.8.0.2:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 39ms, Maximum = 64ms, Average = 48ms
Configuração minimalista do iptables
# Generated by iptables-save v1.8.7 on Sun Apr 14 14:57:35 2024
*filter
:INPUT DROP [0:0]
:FORWARD DROP [119314:15037722]
:OUTPUT ACCEPT [169491:32755967]
:DOCKER-USER - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -j ACCEPT
-A FORWARD -j DOCKER-USER
-A FORWARD -i wg0 -j ACCEPT
-A FORWARD -o wg0 -j ACCEPT
-A DOCKER-USER -j RETURN
COMMIT
# Completed on Sun Apr 14 14:57:35 2024
# Generated by iptables-save v1.8.7 on Sun Apr 14 14:57:35 2024
*nat
:PREROUTING ACCEPT [222:56161]
:INPUT ACCEPT [14:1327]
:OUTPUT ACCEPT [248:13567]
:POSTROUTING ACCEPT [256:16075]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Sun Apr 14 14:57:35 2024
Provavelmente o nome da interface LAN foi alterado no servidor WireGuard ou você adicionou anteriormente uma regra adhoc iptables às conexões NAT encaminhadas para ele, que foi perdida quando o servidor foi reinicializado.
O padrão geral para mascarar conexões WireGuard de um servidor WireGuard para sua LAN é, no servidor:
sysctl net.ipv4.conf.all.forwarding=1
, ).iptables -A FORWARD -i wg0 -j ACCEPT
e vice-versa)iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
)E nos clientes:
AllowedIPs
configuração.Você tinha todas essas coisas - mas tinha o nome de interface errado em sua regra NAT;
eth0
é o nome tradicional para a primeira interface Ethernet, mas em muitas distribuições Linux pode ser algo diferente .Um bom conjunto de comandos para executar no servidor para verificar o que pode estar errado é:
Se tudo mais falhar, você também pode tentar executar
tcpdump
em cada host (como este artigo sobre solução de problemas do WireGuard com Tcpdump descreve) para tentar identificar exatamente onde o tráfego está sendo descartado.