Host iptables só com VPN: nomeie o dispositivo tun, não tun+

Escrever -o tun+ parece uma instrução precisa e na verdade é um curinga que abrange cada túnel que o kernel tem. Um segundo cliente VPN, uma ponte de contêineres ou uma interface deixada por uma sessão que caiu satisfazem-no todos, e o host então permite tráfego que a política pretendia impedir. O procedimento abaixo fixa um único nome de dispositivo, ordena as exceções para que o túnel possa realmente formar-se e deixa-lhe um caminho de volta se as regras correrem mal. Cada passo é curto o bastante para ser desfeito sozinho.

Passo 1: registe as regras que tem agora

Antes de alterar uma política padrão, guarde o estado atual para que a reversão seja um comando e não uma memória. iptables-save > /root/iptables.pre escreve cada tabela num ficheiro que pode restaurar, e um segundo terminal com uma sessão root aberta não é paranoia quando a política que vai definir corta a ligação que a transporta. Se trabalha remotamente, agende também um flush como interruptor de segurança.

Depois liste as interfaces, porque um nome que assumiu é um nome que devia ter lido: ip -br link mostra o que existe neste momento, e o túnel não aparecerá enquanto não estiver levantado. Anote os nomes dos dispositivos à medida que os lê.

Passo 2: dê ao túnel o seu próprio nome

OpenVPN aceita dev tun_work na configuração do cliente, e o Linux cria então uma interface exatamente com esse nome em vez de atribuir tun0. O nome mantém-se estável entre reconexões enquanto nada mais o reivindicar, e é isso que torna significativa uma regra que nomeia o dispositivo.

Onde o nome não pode ser controlado, faça corresponder o endereço do túnel ou uma marca de pacote. Ambos funcionam, ambos são mais difíceis de ler e ambos falham mais silenciosamente quando o túnel muda de numeração. Em qualquer caso, faça corresponder uma única coisa e seja explícito sobre qual.

Passo 3: escreva a política com a exceção do endpoint primeiro

Um host só com VPN é um host de negação predefinida com uma lista curta de exceções, e a exceção que mais importa é a que permite ao túnel existir. Construa-a nesta ordem, com a regra do endpoint antes da regra do dispositivo do túnel, para que o handshake tenha para onde ir:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

O endereço e a porta literais do endpoint pertencem ao seu fornecedor, não a esta página. Se o endpoint for um nome de host, resolva-o uma vez e fixe o resultado, porque uma regra não consegue procurar um nome e uma resposta que roda quebrará a política em silêncio após a próxima alteração de DNS. Verifique também a porta, porque os fornecedores que o mudam para TCP 443 precisarão de outra forma de uma regra que ninguém escreveu. Um túnel que só funciona num protocolo é normalmente esta omissão e não uma falha da firewall.

Num router a mesma forma vai para a cadeia FORWARD para os clientes por trás dele, e o tráfego do próprio router precisa das suas próprias regras. Um conjunto de regras que só cobre pacotes encaminhados deixa o SSH e o DNS no caminho antigo, e é assim que um router fica inacessível no momento em que o túnel sobe.

Passo 4: verifique a ordem, não apenas a presença

As regras são avaliadas em sequência, por isso um ACCEPT que chega antes esconde simplesmente o REJECT que adicionou depois. A correspondência established e related é o que deixa as respostas aos seus próprios pedidos de saída voltarem sem abrir um caminho de entrada geral, e colocá-la depois da aceitação do túnel significa que um túnel caído ainda deixa passar tráfego de retorno na sua própria interface.

Mantenha o número de regras pequeno o suficiente para ser lido num só ecrã. Um conjunto de regras que não consegue auditar é aquele que vai remendar acrescentando exceções no topo, e é assim que as políticas de negação predefinida adquirem aos poucos uma margem de permissão predefinida. Conte os ACCEPT antes e depois da alteração.

Passo 5: faça-o sobreviver ao arranque e à família de endereços

As regras introduzidas à mão desaparecem no reinício, por isso carregue-as do serviço de firewall da distribuição ou de uma unidade que corre depois de a interface do túnel existir. Referir tun_work num script executado antes de o OpenVPN arrancar é uma forma comum de produzir um ciclo de arranque com tráfego descartado.

Depois verifique o IPv6 em separado, porque uma boa política de negação predefinida para IPv4 não diz nada sobre a outra família. ip -6 route dir-lhe-á se o host tem uma rota que possa transportar tráfego em torno de um túnel que só trata de IPv4, e o ip6tables ou o nftables precisa das suas próprias regras equivalentes. Teste com um destino IPv6-only em vez de confiar na simetria do conjunto de regras.

Passo 6: verifique e esteja pronto para restaurar

Levante o túnel, confirme que o serviço pretendido funciona e depois experimente algo que a política deve recusar. Restaure com iptables-restore < /root/iptables.pre se a resposta o surpreender, e só então comece a editar regras. A persistência mais um caminho de restauração testado é o que faz disto uma alteração que pode fazer duas vezes.