Túnel dividido do WireGuard: configurar sem rota padrão

Um túnel dividido é definido pelo que você deixa de fora, e o WireGuard toma essa decisão em um único campo. O AllowedIPs do par do cliente seleciona ao mesmo tempo quais destinos passam pelo túnel e filtra quais endereços de origem internos são aceitos, e o wg-quick transforma a mesma lista em rotas de host. Se a lista estiver errada, o túnel ou engole tudo ou não transporta nada.

Decida primeiro a lista de prefixos

Anote os destinos que devem usar o túnel antes de tocar em qualquer arquivo de configuração. Sub-redes de escritório, um intervalo de banco de dados, uma rede de gerenciamento: cada um é um prefixo com um motivo. Tudo o que não está na lista permanece no caminho físico, e esse é todo o sentido do projeto.

Se a lista contém 0.0.0.0/0 ou ::/0, você construiu um túnel completo e deve dizer isso, porque os modos de falha e as expectativas de DNS são diferentes.

Mantenha a lista curta o suficiente para que um revisor possa compará-la depois com a tabela de roteamento.

Configuração do cliente: par, AllowedIPs, DNS

O bloco de interface do cliente contém seu próprio endereço de túnel e sua chave privada. O bloco de par contém a chave pública do servidor, o endpoint e os prefixos do primeiro passo:

[Interface]
Address = 10.9.0.2/32
PrivateKey = <client-private-key>
DNS = 10.20.0.53

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16, 10.30.0.0/24
PersistentKeepalive = 25

O AllowedIPs no cliente é o conjunto de destinos remotos, não o endereço do próprio cliente. A linha de DNS só tem efeito pela integração do resolvedor do wg-quick, então um host sem suporte a resolvconf ou systemd-resolved a ignorará. O PersistentKeepalive mantém um mapeamento NAT vivo e é desnecessário em um caminho direto.

Comente cada prefixo com o serviço a que serve, ou a próxima edição será um palpite.

Configuração do servidor: o ponto de vista oposto

No servidor, a entrada de par representa o cliente, então seu AllowedIPs é o endereço de túnel do cliente, geralmente um /32. Não é a sub-rede do escritório. Copiar a lista do cliente para a entrada do servidor é o erro mais comum do túnel dividido, e ele ou amplia o acesso ou quebra a verificação de origem interna no handshake.

O endereço de interface do próprio servidor e as rotas de que precisa para o escritório são independentes de qualquer entrada de par.

Dois arquivos, dois pontos de vista, um conjunto de prefixos repartido entre eles.

Levante-o e leia as rotas

Inicie a interface com o gerenciador compatível e depois olhe o que ele instalou, não o que você pretendia. O wg-quick deriva as rotas do AllowedIPs; se o perfil define Table = off, nada é instalado e o roteamento é sua responsabilidade. Leia a rota de cada prefixo e confirme que aponta para a interface do WireGuard. Uma lista de rotas vazia geralmente significa que o perfil aplicado não é o que você editou.

Verifique também os contadores de handshake, porque um par sem handshake tem um problema de chave, endpoint ou alcance, não de roteamento.

Escreva o comando exato que você usou, porque a próxima pessoa o executará sob pressão.

Verifique os dois lados e depois registre a reversão

Teste um endereço privado, seu nome interno e um destino que deve permanecer direto. Se o endereço privado funciona e o destino direto agora sai pelo túnel, a lista de prefixos é ampla demais. Se o nome falha enquanto o endereço funciona, a linha de DNS não entrou em vigor. A reversão é um comando, e pertence à mesma nota.

Após uma reconexão, confirme que as rotas continuam lá, porque um gerenciador que reaplica o perfil pode substituir rotas manuais.

Mantenha um único dono da configuração, porque dois gerenciadores produzindo a mesma interface acabarão discordando. O manual do wg-quick documenta o comportamento de rotas e DNS que oferece.