Endereços de túnel estáticos no pfSense: preferência ou reserva?

Dois desenhos parecem semelhantes no papel e se comportam de forma muito diferente quando uma regra depende deles. Um digita um endereço numa substituição de cliente e confia no endereço como identidade. O outro fecha totalmente a admissão dinâmica, de modo que um endpoint tem uma atribuição única ou não se conecta. Apenas o segundo transforma um endereço num dado de política que você pode defender, e a diferença vale a pena entender antes de escrever uma única regra de firewall.

O que um endereço de substituição realmente promete

Uma substituição específica de cliente carrega opções por cliente, incluindo um endereço de túnel preferido. A Netgate descreve esse endereço como uma preferência e não como uma reserva, o que significa que o pool dinâmico não abre mão do endereço para mais ninguém.

Isso costuma ser aceitável. Uma colisão é rara, e o cliente normalmente recebe o que pediu, o que basta para conveniência e não basta para autorização. Conveniência e autorização são requisitos diferentes, e apenas um deles sobrevive a uma colisão.

Com topologia de sub-rede, o campo usa o endereço do cliente junto com a máscara da rede do servidor, então um endereço dentro de um túnel 10.90.0.0/24 é escrito como 10.90.0.10/24.

Nada disso reserva o número. Um cliente cuja substituição não corresponde, ou uma sessão duplicada, pode acabar em outro ponto do pool, e uma regra baseada no endereço descreve então alguém que não está lá.

Fechar o caminho dinâmico com um padrão delimitado

A alternativa é um servidor apenas estático: cada endpoint admitido tem a sua própria identidade e o seu próprio endereço único, e nada mais entra.

Implementá-lo exige uma substituição DEFAULT limitada a esse único servidor com o bloqueio de conexões ativado. Um cliente sem substituição correspondente não pode então recorrer à admissão dinâmica comum. É essa única linha que converte uma preferência num conjunto fechado.

O escopo importa. Uma substituição padrão aplicada a todas as instâncias de VPN da máquina bloqueará túneis não relacionados, e essa falha parece um serviço quebrado em vez de uma decisão de política. Vincule-a ao único servidor cujo modelo de admissão você está mudando. Depois registe o escopo no registo de alterações, porque a próxima pessoa não vai lembrar-se a que túnel ele pertence.

Audite todo o conjunto permitido depois. O bloqueio padrão não corrige uma substituição nomeada que ficou sem endereço, e esse endpoint simplesmente falhará a conexão sem uma pista óbvia do motivo.

Corresponder à identidade que o servidor realmente usa

Uma substituição corresponde a algo. Num servidor que compara nomes comuns de certificado, o nome da substituição deve ser esse nome comum, não o nome de exibição da pessoa. Copie-o do certificado em vez de o copiar da lista de contas.

Um servidor configurado para usar o nome de utilizador como nome comum compara numa chave completamente diferente, e uma substituição nomeada pelo certificado nunca disparará. Leia a configuração em vez de a inferir do que a lista de contas mostra.

Mantenha os fatores de autenticação adicionais que a implementação exige. Um modelo de endereços fechado muda quem pode conectar-se e que endereço recebe; não substitui a verificação do certificado nem o segundo fator.

Escrever as regras de acesso depois de o mapa estar correto

Uma vez fechado o mapa de identidade para endereço, as regras podem referir endereços sem fingir que são pessoas. Um alias que agrupa os endpoints de uma pessoa pode alcançar um serviço específico enquanto outro alias alcança outra coisa. O alias torna-se o objeto verificável, e o endereço torna-se um detalhe de implementação dentro dele.

Mantenha destinos e portas explícitos. Permitir toda a rede local a partir de todo o pool de túneis é exatamente o desenho que este exercício devia substituir.

Leia as regras flutuantes, de grupo e de interface na sua ordem real de avaliação, porque uma passagem ampla anterior anula uma estreita posterior. Desativar o encaminhamento interno de cliente para cliente mantém o tráfego entre pares na fronteira onde essas regras são revistas. Uma regra que só existe no papel não é aplicação.

Testar os casos negativos

Exercite quatro conexões novas: um endpoint nomeado, um sem qualquer substituição, um serviço que deveria estar acessível e um que não deveria. O endpoint não listado é o caso importante, porque é aquele que o desenho existe para travar. Se ele se conectar, o bloqueio padrão não está a cumprir o seu papel.

Verifique o IPv6 separadamente, pois uma política de endereços IPv4 nada diz sobre uma segunda pilha. Depois confirme que a aplicação ainda autoriza o utilizador, porque um endereço de túnel é um facto de rede e não prova de quem está no teclado. Ambas as verificações pertencem à nota de aceitação.

Por fim, planeie a migração. Novas substituições e regras estreitas não alteram retroativamente sessões já estabelecidas, portanto os estados existentes têm de expirar ou ser limpos deliberadamente.