Como dar a uma LAN de testes a sua própria saída WireGuard

Três desenhos resolvem o mesmo problema de laboratório: uma LAN pequena tem de sair por um par WireGuard enquanto a gateway conserva o seu uplink habitual. O atalho tentador é mover a rota predefinida do router para dentro do túnel, mas isso quebra o próprio caminho de gestão da máquina e tudo o que ela reencaminha. A opção interessante é o encaminhamento por políticas limitado a uma interface e a um prefixo. Escolha entre elas respondendo a três perguntas sobre a máquina que realmente tem.

Decida onde vive a saída

Primeira pergunta: este host reencaminha para mais alguma coisa? Uma gateway de laboratório dedicada pode viver com uma política de reencaminhamento que descarta por predefinição. Um router com deveres de produção não pode, e sobrepor um conjunto de regras concorrente a uma firewall gerida é exatamente como se agendam as falhas. Segunda: pode possuir dois objetos de política e a sua ordem entre reinícios? Terceira: o par que tem autoriza o endereço de origem do seu túnel e oferece saída para a internet? Um par que só expõe uma rede privada é outro produto, e nenhuma alteração local de encaminhamento resolve isso. Se alguma resposta for não, coloque a saída num espaço de nomes ou numa máquina virtual descartável.

Um espaço de nomes ou uma VM custam memória e dão-lhe um raio de impacto limpo. O encaminhamento por políticas custa duas regras e deixa-lhe uma só máquina para depurar.

Escolha a saída que autoriza a sua origem

A maioria das falhas neste laboratório acontece antes de existir uma única regra de firewall. O operador da saída tem de aceitar o endereço de origem que os seus pacotes transportam após a tradução, que neste desenho é o endereço do túnel e não o prefixo da LAN. Por isso o mascaramento faz parte do desenho desde o início e não como um acrescento tardio.

Confirme três coisas com o operador: o par autoriza o endereço do seu túnel, reencaminha IPv4 em vez de terminar em si mesmo e aplica NAT de saída. Sem a primeira, os seus pacotes chegam e desaparecem. Sem a terceira, saem com uma origem privada e morrem no salto seguinte. Depois verifique que o wg-quick não instala a sua própria rota predefinida, o que Table = off impede; essa definição suprime a criação de rotas, não as verificações de AllowedIPs do par nem o seu tratamento de DNS.

Dois objetos de política fazem o encaminhamento

O encaminhamento precisa de uma tabela e de uma regra. A tabela contém duas rotas: o prefixo da LAN para fora da interface LAN e uma predefinida para fora do túnel. A regra envia para a tabela o tráfego que chega à interface LAN e transporta esse prefixo. Use o seletor iif juntamente com a correspondência de origem, porque os pacotes WireGuard da própria gateway nascem localmente e nunca correspondem a uma interface de entrada.

O guarda vem antes da consulta, não depois. Essa ordem é toda a propriedade de segurança do desenho.

O guarda é uma segunda regra no mesmo seletor cujo veredicto é unreachable. Dê-lhe uma prioridade numérica mais alta para que a consulta continue a ganhar enquanto o túnel está levantado. Quando a rota do túnel desaparece, a consulta não devolve nada e o guarda trava a procura em vez de a deixar cair para a rota predefinida WAN da tabela principal.

ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0

Feche a lacuna de recuo antes de a abrir

Instale primeiro o guarda e a consulta depois. Fazer o contrário deixa uma janela de segundos durante a qual o tráfego de um cliente de testes pode alcançar o uplink.

O filtro completa o quadro. No gancho forward aceite a direção da LAN para o túnel para o prefixo de testes e a direção de retorno estabelecida, e depois descarte tudo o resto; o NAT desse prefixo para a interface do túnel fica em postrouting. É precisamente deixar policy drop na cadeia de reencaminhamento que transforma uma rota em falta em silêncio em vez de fuga. A filtragem de caminho inverso exige modo permissivo na interface do túnel, porque uma origem pública que chega desencapsulada tem a sua melhor rota inversa do lado WAN. O Linux toma o maior dos valores all e por interface, pelo que definir a interface do túnel não é o mesmo que enfraquecer a validação em todo o lado.

Prove-o com o caso de falha

Faça ao kernel uma pergunta precisa, nomeando o endereço de origem do cliente e a interface por onde chega. Uma consulta sem ambos responde a outra pergunta e parecerá correta nos dois casos. Depois olhe para os contadores da firewall, o estado de transferência do par e o serviço do próprio cliente.

Teste a remoção como deve ser. Pare o túnel deixando a regra e o filtro no lugar: o cliente deverá bloquear e o tráfego próprio da gateway deverá continuar a funcionar. Depois pare o par sem tocar na interface local, e é esse o caso que apanha desenhos que confiam apenas na presença da rota. Por fim reinicie e volte a verificar a ordem das regras, porque um gancho de desmontagem que remove o guarda devolve todo o desenho à tabela principal. Anote o número da tabela, as prioridades e os nomes das interfaces no ticket de alteração, porque a próxima pessoa a acrescentar uma regra será a que quebra isto.