Bloquear IPv6 para proteger o WireGuard quebra o host

O objetivo é razoável: só os utilizadores do túnel devem chegar aos serviços desta máquina. A implementação a que se recorre é uma cadeia de entrada IPv6 que descarta tudo excepto WireGuard, e isso também descarta o tráfego que mantém o host ligado ao seu próprio link. A descoberta de vizinhos e as mensagens de manutenção do caminho não são acesso a serviços, e removê-las produz uma máquina inalcançável por razões alheias à sua política. O túnel sobe, os serviços estão correctamente delimitados, e nada mais no link funciona.

Três responsabilidades, um conjunto de regras

A primeira responsabilidade é a operação da rede exterior: o host tem de permanecer ligado ao seu link, resolver vizinhos e conhecer os limites de caminho desse link. A segunda é o ouvinte cifrado, que aceita UDP no endereço e na porta que escolheu. A terceira é o conjunto de serviços decifrados que quer que os utilizadores do túnel alcancem.

São três políticas diferentes, e só a segunda e a terceira dizem respeito à VPN. Um conjunto de regras que as trata como uma só herda um modo de falha em que apertar a fronteira da aplicação quebra silenciosamente a ligação do host.

Mantenha-as em cadeias separadas ou pelo menos em comentários separados, para que a pessoa seguinte veja que linha existe e porquê.

O que o ICMPv6 faz pelo host

O IPv6 depende do ICMPv6 para muito mais do que o eco. O pedido e o anúncio de vizinho substituem o ARP e são necessários para a entrega local. O Packet Too Big transporta informação de MTU do caminho, e ignorá-lo produz transferências que encravam em pacotes grandes. Os anúncios de router transportam a rota predefinida e a informação de prefixo quando o link usa configuração automática.

O RFC 4890 separa as mensagens que um filtro de host tem de permitir das que são uma escolha administrativa, e fá-lo numa secção de host diferente das regras para um router que reencaminha entre redes. Ler apenas a secção de reencaminhamento produz uma política de entrada demasiado estrita para o host que protege.

A regra prática é permitir as mensagens essenciais de erro e configuração na interface que precisa delas, limitadas por tipo e origem onde a plataforma o permitir, e tomar uma decisão explícita quanto ao resto.

Substituir tudo isto por uma permissão geral de ICMPv6 resolve o problema de disponibilidade e abdica da filtragem. Substituí-lo por um descarte geral resolve o problema de filtragem e abdica do host.

Admita o túnel, depois o serviço

Aceite o transporte WireGuard no endereço exterior previsto e na porta UDP, e aceite o tráfego de retorno através do seguimento de ligações. Depois permita os serviços de aplicação pela interface do túnel, a partir das origens que realmente autoriza.

Uma permissão para a porta UDP exterior não autoriza os pedidos decifrados lá dentro. Essa distinção é o motivo inteiro de a interface do túnel aparecer nas regras de serviço.

Leia o conjunto de regras tal como é, não como o ficheiro o descreve:

sudo nft list ruleset
ip -6 addr show
ip -6 route show default

Um ouvinte num endereço físico é uma exposição separada do mesmo serviço no endereço do túnel. Se a máquina também reencaminhar tráfego para outra, isso é uma decisão da cadeia de reencaminhamento e não desta política de entrada, e exige a sua própria justificação.

Teste o link, não apenas o túnel

Um túnel a funcionar depois da alteração prova menos do que parece, porque uma entrada de vizinho existente e uma ligação estabelecida podem esconder uma mensagem de controlo que a política agora descarta.

Verifique a ligação directamente e depois verifique que o caminho excluído continua a falhar:

ip -6 neigh show
ping -6 -c 3 2001:db8:1::1
sudo nft -c -f /etc/nftables.conf

Uma tabela de vizinhos que permanece completa após um reinício é o sinal de que a descoberta ainda funciona. Uma tabela que se esvazia e nunca volta a encher é o sinal de que a filtrou. O terceiro comando valida a sintaxe do conjunto de regras sem o aplicar, o que vale a pena fazer enquanto ainda tem sessão.

Recupere um host de que ficou de fora

Antes de alterar regras de firewall que transportam a sua própria sessão de administração, mantenha um segundo canal: uma consola, uma ligação série ou um retrocesso agendado que remove as novas regras se não o cancelar.

Se uma alteração o deixar de fora, a recuperação passa por esse canal e não pela rede que acabou de remover. Restaure o conjunto de regras anterior a partir de uma cópia guardada, confirme que o host volta a ser alcançável e só então reaplique a política prevista em peças mais pequenas.

A política final não é universal. O endereçamento, o encaminhamento e a implementação da firewall são entradas de implantação, mas a fronteira é a mesma em todo o lado: negue o acesso não desejado às aplicações mantendo o tráfego de controlo que transporta o túnel autorizado.