WireGuard: como acessar a LAN de casa

Por que a sua LAN doméstica não responde através do WireGuard

Para encaminhar tráfego para a sua LAN doméstica através do WireGuard, quatro configurações distintas têm de estar coerentes. Três em quatro ainda permitem um túnel que parece perfeitamente saudável, o que torna esta falha tão confusa. wg show indica um handshake recente, ping 10.8.0.1 responde em poucos milissegundos e ping 192.168.20.10 não devolve nada.

Esta é a lista completa, pela ordem em que um pacote passa por cada ponto. LAN significa rede local, a rede privada atrás do router doméstico.

1. AllowedIPs no cliente tem de abranger a sub-rede remota. Caso contrário, o pacote nunca entra no túnel.
2. AllowedIPs no servidor tem de abranger o endereço do túnel do cliente. Caso contrário, o pacote é descartado assim que é desencriptado.
3. net.ipv4.ip_forward tem de ser 1 no servidor, porque o Linux descarta qualquer pacote que não seja destinado ao próprio sistema.
4. A LAN tem de conhecer uma rota de retorno para 10.8.0.0/24, através de uma regra de masquerade no servidor ou de uma rota estática no router doméstico.

Cada um destes pontos pode falhar sem apresentar uma mensagem de erro. Nada é registado, não aparece nenhum aviso e o handshake continua a funcionar durante todo o processo. Verifique-os pela ordem indicada. O ponto com problemas será identificado em cerca de um minuto.

A rede usada neste guia

Todos os endereços abaixo são exemplos. Substitua-os pelos seus próprios endereços e mantenha a substituição consistente, porque uma configuração atualizada apenas parcialmente é a segunda causa mais comum deste problema.

• A LAN doméstica é 192.168.20.0/24. O router doméstico é 192.168.20.1.
• O servidor WireGuard é uma máquina Linux nessa LAN. A interface LAN enp1s0 contém 192.168.20.5, e a interface de túnel wg0 contém 10.8.0.1.
• O host que pretende alcançar é um NAS (armazenamento ligado à rede) em 192.168.20.10.
• O cliente é um portátil noutro local, 10.8.0.2 dentro do túnel.

O servidor é uma máquina na LAN, não o próprio router. Este é o caso normal: um Raspberry Pi ou um mini PC antigo. Isto é importante para a regra 4: o router não sabe que o túnel existe até o configurar, e todos os hosts da LAN enviam o tráfego destinado a outras sub-redes para esse router.

Se a sua ligação doméstica não tiver um endereço IP público, nada disto funciona por si só, porque nenhum sistema na internet consegue iniciar um handshake com a sua rede doméstica. A secção sobre utilizar um VPS como intermediário aborda esse caso. As mesmas quatro regras aplicam-se, com um peer adicional que precisa de configurar corretamente.

AllowedIPs tem dois significados diferentes

Uma configuração executa duas funções, e interpretá-la da mesma forma nas duas extremidades é o erro por trás da maioria destes pedidos de suporte. O WireGuard chama a este mecanismo encaminhamento por chaves criptográficas, descrito em mais detalhe em como o WireGuard associa chaves públicas a intervalos de IP.

Lido no sentido de saída, AllowedIPs é uma tabela de encaminhamento. wg-quick transforma cada entrada numa rota que aponta para wg0. Um pacote destinado a 192.168.20.10 só é encriptado e enviado para um peer se algum peer declarar um intervalo que contenha esse endereço. Liste apenas 10.8.0.0/24 e o seu portátil enviará o tráfego da LAN pela rede Wi-Fi local, onde o tráfego pode ser descartado ou chegar a um 192.168.20.10 completamente diferente.

Lido no sentido de entrada, AllowedIPs é uma lista de controlo de acesso. Depois de desencriptar um pacote recebido de um peer, o WireGuard compara o endereço de origem interno com os AllowedIPs desse peer e descarta o pacote se não houver correspondência. Não existe uma linha no log nem um contador para esse descarte. O pacote simplesmente desaparece.

Por isso, os dois ficheiros de configuração nunca são imagens espelhadas. O cliente lista aquilo a que pretende chegar através do servidor. O servidor lista os endereços de origem que esse cliente está autorizado a utilizar.

O par correspondente de ficheiros de configuração

Cliente, /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = <laptop private key>
Address = 10.8.0.2/32

[Peer]
PublicKey = <server public key>
Endpoint = home.example.com:51820
AllowedIPs = 10.8.0.0/24, 192.168.20.0/24
PersistentKeepalive = 25

Servidor, /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = <server private key>
Address = 10.8.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <laptop public key>
AllowedIPs = 10.8.0.2/32

O router doméstico também precisa de um redirecionamento de porta, UDP 51820 para 192.168.20.5. Caso contrário, o handshake nunca começa e os logs do cliente mostram Handshake for peer 1 did not complete after 5 seconds, retrying. Este guia parte do princípio de que já ultrapassou esse ponto.

Quatro linhas diferem de uma configuração simples de túnel completo, e cada uma existe por uma razão específica.

• AllowedIPs = 10.8.0.0/24, 192.168.20.0/24 no cliente, em vez de 0.0.0.0/0, ::/0. Este é um túnel dividido: a sub-rede do túnel e a LAN doméstica passam por wg0, enquanto todo o restante mantém a rota local. A navegação web não passa pela ligação doméstica, o que normalmente é o comportamento pretendido quando só precisa de aceder ao NAS.
• AllowedIPs = 10.8.0.2/32 no servidor, com um endereço em vez de um intervalo. Escreva 10.8.0.0/24 nesse campo, e esse cliente poderá usar qualquer endereço dentro do túnel. Se adicionar posteriormente um segundo peer com um intervalo sobreposto, o tráfego passa para o peer configurado por último, sem que seja apresentada qualquer mensagem de erro.
• PersistentKeepalive = 25 apenas no cliente. O cliente está atrás de NAT (network address translation), e o router elimina o mapeamento UDP após um ou dois minutos de silêncio. O servidor deixa então de conseguir alcançá-lo. O servidor tem um endereço público e não precisa de keepalive.
• Ainda não existe uma linha DNS =. Adicioná-la altera a resolução de nomes em toda a máquina cliente. A secção sobre DNS abaixo explica o efeito dessa linha antes de a ativar.

Um túnel completo também permite aceder à LAN, porque 0.0.0.0/0 corresponde a todos os endereços. No entanto, encaminha todo o seu tráfego pelo túnel e pode causar um conflito de sub-redes que não consegue resolver a partir do cliente.

Por que a mesma sub-rede nas duas extremidades causa falha

Escolha uma sub-rede doméstica que quase ninguém use, como 192.168.20.0/24 ou 10.44.7.0/24. 192.168.1.0/24 e 192.168.0.0/24 são os valores predefinidos de fábrica na maioria dos routers de consumo. Mais cedo ou mais tarde, o seu portátil vai estar numa rede Wi-Fi de um café ou hotel que usa exatamente esse intervalo.

A colisão impede a ligação e manifesta-se de forma diferente nos dois casos. Com um túnel dividido, wg-quick tenta adicionar uma rota para um prefixo que já existe na interface Wi-Fi, ip route add recusa a operação e a interface não é ativada:

RTNETLINK answers: File exists

Com um túnel completo, wg-quick instala regras de encaminhamento por política que mantêm deliberadamente as rotas mais específicas fora da tabela principal. A rota local 192.168.1.0/24 tem precedência sobre o túnel, por isso todos os pacotes destinados à LAN remota saem pela ligação local. O túnel está ativo, o handshake funciona e o NAS fica inacessível. Renumerar a LAN doméstica é a única correção real.

Transformar o servidor num router

ip route show default
printf 'net.ipv4.ip_forward = 1\n' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

O primeiro comando mostra o nome real da interface LAN. As imagens atuais usam nomes como enp1s0 ou ens3, e raramente eth0. Uma regra de masquerade que indique a interface errada não corresponde a nenhum pacote. O último comando deve mostrar net.ipv4.ip_forward = 1. Um sudo sysctl -w simples define o mesmo valor, mas perde-se depois do próximo reboot. Este é o motivo clássico do relato “funcionou até terça-feira”.

O encaminhamento também tem de sobreviver à firewall. No Ubuntu com o ufw ativo, os pacotes encaminhados são descartados, a menos que DEFAULT_FORWARD_POLICY="ACCEPT" esteja definido em /etc/default/ufw. O Docker define essa política por conta própria. Por isso, se sudo iptables -S FORWARD | head -1 mostrar -P FORWARD DROP num sistema em que nunca configurou a firewall manualmente, foi o Docker que o fez. O tráfego do túnel precisa de uma regra de aceitação explícita.

Por que as respostas nunca regressam

Se acertar nas regras 1 a 3, o ping chega realmente ao NAS. Ainda assim, não vê nada, porque a resposta não tem caminho de regresso. O NAS responde para 10.8.0.2, um endereço fora da sua própria sub-rede, por isso entrega o pacote ao gateway predefinido, o router doméstico em 192.168.20.1. Esse router nunca ouviu falar de 10.8.0.0/24, por isso encaminha a resposta para o próprio gateway predefinido, a ligação à Internet, onde o pacote é descartado. O pedido chega, mas a resposta é eliminada.

Opção A: masquerade no servidor WireGuard. O servidor reescreve o endereço de origem de todos os pacotes encaminhados para 192.168.20.5, o seu próprio endereço na LAN. O NAS passa a ver um pedido proveniente de um vizinho da mesma sub-rede, responde diretamente ao servidor, e o servidor reverte a reescrita e envia o pacote de volta pelo túnel. Não é necessário alterar mais nada na LAN.

Coloque a regra no bloco [Interface] do servidor, para que apareça e desapareça juntamente com a interface:

PostUp = iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o enp1s0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.8.0.0/24 -o enp1s0 -j MASQUERADE

Num sistema que já seja gerido por nftables, escreva-a em /etc/nftables.conf:

table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 10.8.0.0/24 oifname "enp1s0" counter masquerade
  }
}

Mantenha a palavra-chave counter. Sem ela, sudo nft list ruleset apresenta a regra sem contador de pacotes, e esse contador indica precisamente se a regra está a ser utilizada.

O masquerade traz uma segunda vantagem que é fácil não detetar. Muitos hosts executam uma firewall que só aceita ligações provenientes da própria sub-rede. A partilha de ficheiros do Windows funciona assim por predefinição, tal como vários painéis de administração de NAS. Um pacote proveniente de 10.8.0.2 é descartado pelo host de destino mesmo quando o encaminhamento está correto. Com o masquerade, a origem passa a ser um endereço da LAN, por isso essas regras correspondem. O custo é que todos os clientes do túnel aparecem como 192.168.20.5 nos logs de todos os hosts da LAN. Assim, não é possível distinguir os clientes, e as regras por cliente nos dispositivos da LAN não podem funcionar.

Opção B: uma rota estática no router doméstico. Indique ao router que 10.8.0.0/24 está atrás de 192.168.20.5. Num router Linux, isso requer um único comando:

sudo ip route add 10.8.0.0/24 via 192.168.20.5

Os routers de consumo têm normalmente uma página chamada Static Routes ou Routing nas definições avançadas: destino 10.8.0.0, máscara 255.255.255.0, gateway 192.168.20.5. Guarde a configuração no armazenamento persistente do router, porque um ip route add introduzido num sistema Linux desaparece no reboot seguinte.

Esta opção preserva o endereço real do cliente, por isso os logs e as regras por cliente na LAN continuam a ser úteis. É necessário um router que suporte rotas estáticas, e a opção só ajuda os hosts que utilizem esse router como gateway predefinido. Qualquer host com uma firewall local limitada à sub-rede continua a precisar da sua própria regra para 10.8.0.0/24. Comece pelo masquerade, porque não requer alterações fora do sistema que já controla, e passe para a rota estática quando precisar dos endereços reais dos clientes.

Como descobrir qual dos quatro está errado

Comece pelo cliente e avance para fora. Cada passo mostra se o pacote chegou até esse ponto.

O pacote entra no túnel? No cliente:

ip route get 192.168.20.10

A resposta deve indicar dev wg0. Se indicar a interface Wi-Fi, a regra 1 está errada e o AllowedIPs do cliente não abrange a sub-rede LAN. Um ping: connect: Network is unreachable aponta para a mesma linha.

Os pacotes chegam ao servidor? Execute isto no servidor e, em seguida, faça ping ao NAS a partir do cliente:

sudo tcpdump -ni wg0 icmp

Um caminho funcional mostra IP 10.8.0.2 > 192.168.20.10: ICMP echo request, em que ICMP significa internet control message protocol, o protocolo usado por ping. Se não aparecer nada, mas o handshake estiver correto, o problema é a regra 2: o AllowedIPs do servidor para esse peer não inclui 10.8.0.2. Por isso, o pacote foi descartado durante a desencriptação, antes de chegar a wg0.

Eles saem para a LAN? No servidor, monitorize o lado da LAN:

sudo tcpdump -ni enp1s0 icmp

Pedidos visíveis em wg0, mas não aqui, indicam um problema na regra 3. O encaminhamento está desativado ou uma regra FORWARD descartou o pacote. Pedidos visíveis aqui com origem 10.8.0.2, mas sem respostas, indicam um problema na regra 4. A resposta não tem uma rota de retorno. Pedidos visíveis aqui com origem 192.168.20.5, mas sem respostas, indicam que a regra de masquerade está a funcionar e que o próprio host de destino está a recusar a ligação. Nesse caso, verifique a firewall do NAS. A mesma sequência funciona para qualquer outro serviço depois de substituir icmp por port 445 ou pela porta que pretende verificar.

Consigo alcançar o IP, mas não o nome

ssh 192.168.20.10 funciona e ssh nas.home.arpa falha:

ssh: Could not resolve hostname nas.home.arpa: Name or service not known

Não há nenhum problema com o túnel. A resolução de nomes é um caminho separado, e o portátil continua a consultar o resolvedor que aprendeu através da rede Wi-Fi local. Esse resolvedor não conhece os nomes da sua rede doméstica.

Para os nomes domésticos funcionarem, têm de se verificar duas condições. O endereço do resolvedor tem de estar dentro de AllowedIPs no cliente; caso contrário, a consulta DNS (sistema de nomes de domínio) nunca entra no túnel. Além disso, o resolvedor tem de aceitar uma consulta cujo endereço de origem seja 10.8.0.2. Muitos resolvedores domésticos recusam consultas por predefinição: dnsmasq executado com local-service responde apenas a consultas provenientes de uma sub-rede diretamente ligada, e o Pi-hole inclui um modo de escuta que permite apenas pedidos locais. Uma regra de masquerade oculta este problema, porque, depois da reescrita, a consulta chega com origem em 192.168.20.5.

No lado do cliente, basta uma linha:

DNS = 192.168.20.1

Num cliente Linux, é necessário definir openresolv ou um equivalente. Caso contrário, wg-quick termina com resolvconf: command not found. Antes de o definir, confirme o comportamento numa máquina com systemd-resolved: wg-quick regista esses servidores exclusivamente. Assim, enquanto o túnel estiver ativo, todas as consultas do portátil vão para o resolvedor doméstico, e não apenas os nomes domésticos. Verifique o resultado com resolvectl status wg0. Se quiser que os nomes domésticos sejam resolvidos em casa e que todo o resto seja resolvido localmente, isso é split DNS. Corrigir o DNS através de um túnel WireGuard explica toda a configuração.

Sem IP público em casa? Use um VPS como intermediário

Se a página de estado do router mostrar um endereço WAN dentro de 100.64.0.0/10 ou um endereço 192.168.x.x privado, está atrás de CGNAT (carrier grade network address translation) e nenhum handshake da internet consegue chegar à sua casa. Um handshake de saída continua a funcionar normalmente. A solução é usar um terceiro nó com um endereço público. Um VPS pequeno funciona como hub, e o equipamento de casa liga-se a ele através de uma ligação de saída.

As quatro regras não mudam. Agora aplicam-se a dois saltos, pelo que o registo das configurações duplica.

• No VPS, a entrada do peer do equipamento de casa recebe AllowedIPs = 10.8.0.3/32, 192.168.20.0/24: o próprio endereço do túnel, além da sub-rede pela qual está autorizado a comunicar.
• No VPS, a entrada do peer do laptop continua a receber AllowedIPs = 10.8.0.2/32.
• No laptop, o peer do VPS recebe AllowedIPs = 10.8.0.0/24, 192.168.20.0/24, porque agora todo o tráfego vai para o hub.
• No equipamento de casa, o peer do VPS recebe AllowedIPs = 10.8.0.0/24, e o equipamento de casa anuncia PersistentKeepalive = 25, porque agora é o lado que está atrás de NAT.
• O VPS também precisa de net.ipv4.ip_forward = 1, e a sua cadeia de encaminhamento tem de permitir wg0 para wg0, porque o tráfego do laptop chega e sai pela mesma interface. Uma firewall escrita para um VPS com full-tunnel simples bloqueia precisamente esse tráfego.

Se ainda não configurou a extremidade do VPS, configurar o WireGuard num VPS aborda a geração de chaves, a firewall e a unidade systemd. O padrão mais geral para chegar a uma máquina que não aceita ligações de entrada está descrito em abrir um túnel reverso atrás de CGNAT. Quando deixar de ser prático gerir manualmente os endereços dos peers, executar um router de sub-rede Tailscale faz o mesmo encaminhamento e automatiza o registo dos endereços.

Torne a configuração persistente após um reboot

sudo systemctl enable --now wg-quick@wg0
sudo systemctl enable --now nftables
sudo wg show

enable --now é a etapa que muitas pessoas ignoram. Um wg-quick up wg0 executado manualmente desaparece após a próxima atualização do kernel e o reboot. wg show deve listar o peer com uma linha latest handshake recente e contadores de transferência diferentes de zero nas duas direções.

Adicionar um segundo cliente mais tarde não exige um reinício, que desligaria todas as ligações existentes:

sudo bash -c 'wg syncconf wg0 <(wg-quick strip wg0)'

wg-quick strip apresenta a configuração sem as chaves que apenas o wg-quick entende, e syncconf aplica a diferença enquanto as sessões ativas continuam a funcionar. Atualiza apenas os peers. Uma alteração em Address ou uma nova linha PostUp ainda exige um down e up completos.

FAQ

Por que consigo fazer ping ao servidor WireGuard, mas não a mais nada na LAN doméstica?

Fazer ping a 10.8.0.1 apenas prova que o túnel está ativo. O acesso ao resto da LAN é um problema de encaminhamento. O AllowedIPs do cliente tem de incluir 192.168.20.0/24, caso contrário o pacote nunca entra no túnel. No servidor, net.ipv4.ip_forward tem de estar definido como 1, caso contrário ele descarta tudo o que não lhe é destinado. A LAN também precisa de uma rota de retorno para 10.8.0.0/24. Execute sudo tcpdump -ni enp1s0 icmp no servidor enquanto faz o ping: pedidos que saem com a origem 10.8.0.2 e não recebem respostas indicam que falta o caminho de retorno.

Preciso de uma rota estática no router doméstico?

Apenas se não utilizar a regra de masquerade. Uma regra de masquerade no servidor WireGuard reescreve o endereço de origem do tráfego do túnel para o próprio endereço do servidor na LAN. Assim, os hosts da LAN respondem a um vizinho que já sabem alcançar, e o router não é envolvido. A alternativa é uma rota estática para 10.8.0.0/24 através do endereço do servidor na LAN. Esta opção é útil quando pretende que os endereços reais dos clientes apareçam nos logs dos hosts da LAN ou quando precisa de regras de firewall por cliente nesses hosts.

Por que a mesma sub-rede nas duas extremidades interrompe o túnel?

O portátil não pode manter duas rotas para o mesmo prefixo. Se a rede local atribuir 192.168.1.0/24 e a LAN doméstica também for 192.168.1.0/24, um túnel dividido wg-quick up falha quando ip route add recusa com RTNETLINK answers: File exists. Um túnel completo é estabelecido, mas wg-quick instala regras de política que mantêm as rotas mais específicas fora da tabela principal. Assim, a rede local tem prioridade e a LAN remota continua inacessível. Renumere a LAN doméstica para uma rede pouco utilizada, como 192.168.20.0/24. Não existe uma correção do lado do cliente.

Consigo aceder ao NAS pelo endereço IP, mas não pelo nome. O que falta?

A resolução de nomes não segue o túnel automaticamente. Adicione DNS = 192.168.20.1, o seu resolvedor doméstico, ao bloco [Interface] do cliente e confirme que esse endereço está incluído em AllowedIPs do peer. Caso contrário, a consulta nunca entra no túnel. Depois, confirme que o resolvedor responde a consultas externas à própria sub-rede, porque dnsmasq com local-service e o modo de escuta apenas local do Pi-hole recusam essas consultas. Uma regra de masquerade no servidor WireGuard contorna o problema ao reescrever o endereço de origem da consulta.

A minha ligação doméstica não tem um IP público. Ainda posso aceder à minha LAN?

Sim, com um terceiro nó. Atrás de CGNAT, o endereço WAN do router é privado. Por isso, nenhum peer na internet pode iniciar um handshake com ele, embora um handshake de saída funcione normalmente. Execute o WireGuard num VPS com um endereço público e faça o equipamento doméstico ligar-se a esse VPS com PersistentKeepalive = 25. No VPS, configure a entrada do peer correspondente ao equipamento doméstico com um AllowedIPs que contenha o endereço do túnel e 192.168.20.0/24. Depois, ative o encaminhamento no VPS e crie uma regra de forward que permita wg0 para wg0.