Como bloquear a saída do Linux para que nada vaze quando a VPN cair

Imagine uma caixa de mídia numa ligação doméstica que só deve alcançar a internet através de um túnel. Quando o túnel cair, a aplicação deve parar em vez de continuar silenciosamente pela interface física. Obter esse comportamento é um problema de firewall e não de encaminhamento, e a distinção importa porque uma rota pode ser substituída por um reinício do daemon, enquanto um filtro fica onde o colocou. A seguir veremos como o caminho do pacote realmente decide e depois como limitar as exceções que mantêm o túnel a reconectar.

A saída local é um gancho diferente do encaminhamento

Um pacote que sai de uma aplicação na máquina atravessa o gancho de saída; um pacote que a máquina encaminha para outro host atravessa o encaminhamento. Uma política que menciona apenas forward restringe o segundo e deixa o primeiro completamente aberto, e é por isso que tantos bloqueios de saída parecem corretos e não fazem nada. A correspondência de interface pertence à mesma regra: oifname "tun0" accept deixa passar o tráfego que já foi encaminhado pelo túnel. Encaminhamento e filtragem também continuam a ser decisões separadas, pelo que uma rota de ligação pode existir enquanto o filtro rejeita o pacote. É nessa separação que confia.

Um gateway que encaminha para outros dispositivos precisa dos dois ganchos. Bloquear apenas a saída protege a máquina e deixa cada cliente a jusante livre para vazar.

Escreva a lista de exceções do endpoint para fora

Comece pelo endpoint do túnel: um endereço de destino ou um conjunto pequeno aprovado, o protocolo de transporte e a porta de destino, por exemplo udp dport 1194 ip daddr 203.0.113.7 accept. Se o cliente resolve um nome de host, a troca de DNS inicial precisa da sua própria regra limitada ao resolver e à porta 53, não de uma permissão geral para o endereço desse resolver. Cada exceção deve nomear o motivo pelo qual existe. Uma autorização para todo o tráfego UDP para a porta da VPN cobre muito mais do que o único serviço autenticado que tinha em mente.

A resolução inicial é onde os bloqueios costumam apodrecer. Um conjunto de endereços atualizado por temporizador precisa de um comportamento definido quando a atualização falha, e esse comportamento não pode ser abrir a ligação até conseguir. Atualize pelo túnel enquanto o túnel está de pé e, caso contrário, volte ao último endpoint saudável conhecido.

A administração local precisa do mesmo tratamento. Uma sub-rede de gestão não é de confiança só porque os endereços são privados, e uma regra que confia nela convida um segundo caminho à volta do bloqueio.

A correspondência de interface não prova um túnel saudável

As regras que aceitam tudo o que sai de tun0 assumem que um pacote nessa interface veio do túnel. Os nomes das interfaces são recriados, e um nome não é uma identidade criptográfica. O par também pode ter desaparecido enquanto a interface continua de pé, o que torna a regra numa inação muito convincente.

O rastreio de ligações acrescenta uma armadilha relacionada. Uma regra ampla para ligações estabelecidas reproduz a permissão que um fluxo obteve antes, pelo que uma sessão iniciada antes da queda do túnel continua a funcionar depois. Restrinja a aceitação com estado às interfaces e endereços que realmente pretende, ou construiu um bloqueio que se abre sozinho. As regras de entrada e de saída também respondem a perguntas diferentes, e endurecer uma ignorando a outra deixa a máquina acessível na direção que não considerou.

O que sobrevive a uma queda do daemon

Um filtro instalado por um script que corre depois de o túnel subir desaparece com o túnel, exatamente no momento em que era necessário. Carregue o bloqueio no arranque e deixe o daemon gerir apenas as suas exceções.

Apagar a rota predefinida também não é substituto. A rota é estado que o daemon possui e reescreve, e removê-la pode tirar o caminho necessário para reconectar. O IPv6 precisa do seu próprio plano, porque a descoberta de vizinhos e os anúncios de router são serviços de ligação que devem continuar a funcionar enquanto o tráfego normal está bloqueado. O DHCP pertence à mesma categoria. Registe estas coisas como exceções com um propósito, em vez de as descobrir mais tarde como falhas.

Caminho de recuperação antes da implementação

Teste o bloqueio tal como vai falhar: arrancar sem túnel, matar o daemon, mudar o endpoint e reconectar. Cada caso deve parar as aplicações e deixar o canal de recuperação a funcionar. Faça-o a partir de uma consola, porque uma shell remota é a sessão com maior probabilidade de ficar bloqueada pela sua própria regra.

Depois verifique até onde uma aplicação comum ainda chega, com um destino inofensivo e um pedido que possa verificar. O resultado que quer é uma recusa na ligação e um sucesso pelo túnel, não um tempo limite ambíguo que possa significar as duas coisas. Mantenha o conjunto de regras sob o mesmo proprietário que o resto da firewall, em vez de substituir toda a tabela a partir de um script de shell. Uma política em que cada permissão consegue justificar-se vale mais do que um conjunto longo de regras que ninguém sabe explicar.