Dois grupos de clientes, um servidor: onde aplicar a política

Colocar dois grupos de clientes em sub-redes diferentes parece isolamento, e não é. Os endereços descrevem de onde um pacote parece vir, enquanto a permissão é uma decisão tomada por quem o encaminha. Essa pergunta é respondida pela configuração e não pela máscara, portanto decida qual componente encaminha o tráfego entre pares antes de escrever qualquer regra.

Uma sub-rede é um rótulo, não uma regra

Atribuir um pool por grupo dá endereços legíveis e nada mais. Um cliente que aceita uma rota adicional ganhou alcançabilidade, e alcançabilidade não é autorização. A permissão para falar está na decisão de encaminhamento, que pode viver no daemon ou no kernel conforme a configuração do servidor.

A propriedade do endereço é o que torna um prefixo utilizável como seletor de grupo. Cada identidade autenticada deve corresponder a um endereço ou intervalo previsível, e esse mapeamento falha assim que vários dispositivos compartilham uma credencial e uma atribuição. Resolva a identidade e a concorrência antes de confiar num prefixo de origem, porque uma política que adivinha qual máquina chama autoriza a errada no pior momento.

Escolha o caminho que transporta o tráfego entre pares

Quando o daemon encaminha pacotes entre pares dentro do próprio processo, esses pacotes nunca chegam ao gancho de encaminhamento do host, então uma regra do kernel não consegue vê-los. Desative esse encaminhamento interno e o kernel passa a ser o ponto de encaminhamento, onde valem as regras de encaminhamento comuns.

# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chain

Canais de dados descarregados e servidores geridos pelo produto publicam os seus próprios modelos de aplicação, por isso confirme qual está a executar em vez de presumir o comportamento da comunidade. A falha que vale a pena evitar é uma regra que parece correta numa revisão e nunca é consultada em tempo de execução.

Escreva a matriz antes de escrever regras

Uma matriz curta é mais fácil de revisar do que um conjunto de regras, e é o contrato que a implementação tem de cumprir: pares do mesmo grupo permitidos, pares entre grupos negados, ambos os grupos permitidos para um serviço partilhado com nome, todo o resto negado. Escreva essas quatro linhas antes de abrir um editor de firewall. Um revisor que não lê a sintaxe das regras ainda pode verificar a matriz. A implementação passa então a ter apenas de corresponder às linhas.

Mantenha as três classes de destino separadas enquanto a escreve. Um serviço no host VPN é entrada local, outro cliente é trânsito entre pares e uma máquina atrás do gateway é um caminho de encaminhamento diferente. Uma regra generosa pode conceder as três por acidente, e é assim que uma política de grupo se transforma numa rede plana com passos extra. Escreva a classe ao lado de cada linha para que a intenção sobreviva à próxima edição.

Coloque as regras onde sobrevivem

Adicione as decisões no mesmo local onde se mantém o resto da firewall, antes de qualquer regra permissiva que de outro modo as engoliria. A ordem das regras faz parte da política, e uma regra correta colocada depois de uma aceitação ampla não aplica nada. Anote os números das regras antes e depois da alteração. Uma política que existe num editor mas não no conjunto de regras em execução é um plano, não um controlo.

Decida o que acontece aos fluxos que já existem quando a política muda, porque uma sessão aberta antes da alteração pode continuar depois. Se um membro que sai tiver de perder o acesso imediatamente, o conjunto de regras precisa de uma forma de terminar esse estado em vez de esperar que a ligação se feche sozinha.

Torne as regras persistentes através do mecanismo que possui o resto da firewall, e registe a matriz ao lado delas. Uma política não registada é novamente derivada da memória durante o próximo incidente, normalmente por alguém com pressa.

Prove-o dos dois lados

Teste a alcançabilidade dentro do mesmo grupo, a falha entre grupos e o serviço partilhado a partir de um cliente em cada grupo. Um único teste a partir de um único cliente prova metade da matriz, e a metade que fica de fora é normalmente a errada. Repita a direção de negação duas vezes, porque uma sessão em cache pode esconder um erro de aplicação. Registe qual o par testado para que a pessoa seguinte não o repita.

Repita a verificação em IPv6 se o túnel o transportar, e mantenha a autenticação normal das aplicações. Um prefixo de origem não é uma conta, por isso passar a política de rede não significa que um serviço deva confiar no chamador.