Por que uma regra de bloqueio de cliente OpenVPN nunca chega ao FORWARD

Dois clientes no mesmo servidor OpenVPN podem se alcançar mesmo depois de você adicionar uma regra DROP para o pool deles. A regra está na cadeia FORWARD, o tráfego flui claramente e o contador dessa regra continua em zero. A conclusão natural é que o firewall está quebrado. Mais frequentemente, o pacote nunca entrou na cadeia.

Existem dois caminhos que um pacote de peer pode seguir através de um servidor OpenVPN, e eles são decididos pela configuração, não pelo firewall. Saber qual caminho está em uso diz se uma regra do host está sequer no lugar certo.

Dois caminhos que um pacote de peer pode seguir

Com a opção de encaminhamento interno desativada, um pacote do cliente A chega à interface do túnel com um destino dentro do endereço atribuído ao cliente B. A tabela de rotas do servidor o envia de volta pela mesma interface do túnel, porque o servidor possui a rota até o endereço de B. É um fluxo de entrada e saída através do host, e o caminho de encaminhamento IPv4 o avalia.

Com a opção de encaminhamento interno ativada, o processo do servidor associa o pacote a um cliente conectado e o grava de volta diretamente nesse cliente. O pacote é tratado dentro do daemon e nunca volta a entrar no dispositivo do túnel, então o caminho de encaminhamento do host é totalmente ignorado. O manual do OpenVPN 2.6 descreve essa opção como encaminhamento interno de cliente para cliente, e é exatamente por isso que uma regra do firewall do host não consegue vê-la.

Existe uma terceira variante em implantações que descarregam o canal de dados para um módulo do kernel. A decisão de encaminhamento e a criptografia saem do espaço do usuário, e se o netfilter observa o fluxo depende de como o caminho de descarga é construído. Nunca presuma que um conjunto de regras antigo se comporta num servidor com descarga como num servidor no espaço do usuário. Confirme o modo a partir da configuração em execução, não da versão do pacote.

Quando o contador nunca se move

Um contador zerado significa que o pacote não coincidiu com aquela regra naquele ponto, e há vários motivos. O primeiro é o desvio acima: o tráfego nunca chegou à cadeia. O segundo é uma incompatibilidade de interface, direção, origem ou destino, o que é comum quando o pool foi renumerado e a regra ainda cita o prefixo antigo.

O terceiro é a posição. Uma regra anterior na cadeia pode aceitar o fluxo antes de a sua DROP ser avaliada, e uma regra posterior pode ser a que realmente decide o resultado. Leia a cadeia em ordem com os contadores visíveis e verifique qual contador aumenta quando você repete o teste.

Faça uma troca controlada entre dois clientes cujos endereços reais você confirmou a partir do estado do próprio servidor, não de uma concessão que você lembra. Se o contador relevante ainda não se mover, suspeite do caminho antes de reescrever a correspondência. Se ele se move mas a conexão ainda funciona, a queda está sendo sobreposta adiante e o problema é a ordem. Essa resposta decide se o reparo é uma mudança de regra ou de topologia, então obtenha-a antes de editar qualquer coisa.

Escolher uma fronteira que possa filtrar

Se a política precisa viver no firewall do host, coloque o tráfego onde o firewall pode vê-lo. Desativar o encaminhamento interno é a forma suportada de fazer o tráfego entre pares atravessar a interface do túnel e o caminho de encaminhamento, ao custo de enviar cada pacote de peer pela pilha do host.

Depois, combine o fluxo com precisão. O tráfego chega à interface do túnel e sai pela interface do túnel, nos dois sentidos, então regras que consideram apenas a interface física não vão coincidir. Regras baseadas em endereço precisam do pool atual e devem considerar o sentido de retorno tanto quanto o de ida.

Muitas implantações são melhor atendidas filtrando no nível do cliente ou do grupo, onde a identidade é conhecida e a política segue o usuário em vez de um endereço que muda na reconexão. Esse é um mecanismo diferente de uma cadeia no host, e os dois não devem ser misturados sem motivo claro.

Não transporte sem alterações o conjunto de regras de uma topologia antiga numa migração. Pools de endereços, nomes de interface e modos de encaminhamento influenciam todos se uma regra coincide, e uma regra copiada que antes funcionava é o tipo de evidência mais enganoso. Comece pelo fluxo que você quer permitir e escreva a regra que coincide com ele.

Testar o isolamento em vez de confiar numa regra

Teste o caso proibido e o caso permitido na mesma execução. Inicie uma nova conexão de um cliente para o outro e confirme que falha, depois confirme que uma conexão que deveria ser permitida ainda funciona. Se apenas o primeiro for testado, um firewall que bloqueia tudo parece um sucesso.

Repita depois de recarregar a configuração do servidor e depois que um cliente se reconectar, porque o encaminhamento interno e as atribuições de pool são estado de execução. Verifique os contadores nos dois sentidos, pois uma regra que coincide num sentido e não na resposta produz isolamento parcial difícil de notar num teste rápido.

O isolamento é o resultado observado na fronteira que realmente transporta o fluxo. Uma regra DROP em algum lugar do host não é evidência; uma conexão que falhou mais um contador deslocado na regra que a causou é.