VPN site a site: qual direção precisa realmente de uma regra?

Ambas as extremidades relatam um túnel estabelecido, a filial remota responde a partir do gateway, e a aplicação continua a expirar para os utilizadores de um lado. O conselho habitual diz para adicionar uma regra de firewall em ambas as direções. Por vezes isso é correto, por vezes duplica uma regra que já existe, e por vezes é a segunda regra que quebra o estado. Qual é o caso depende de onde a firewall vê o pacote.

O tráfego de retorno com estado altera a contagem

Uma firewall com estado registra o pedido e admite a resposta sem uma segunda regra, por isso um desenho que precisa apenas de uma regra é normal. Uma lista de acesso sem estado não tem essa memória, e a resposta tem de ser permitida explicitamente. Ambas estão corretas na sua própria plataforma, e é por isso que os conselhos se contradizem.

Leia a documentação de encaminhamento da plataforma à sua frente e verifique se a política que está a editar tem estado onde vê o pacote. Uma negação explícita para tráfego estabelecido, ou uma ordem de regras que avalia a resposta antes da tabela de estados, transforma um desenho funcional numa incógnita. O número de regras é um detalhe de implementação, enquanto o requisito é que ambas as direções de uma conversa permitida possam terminar.

Onde a firewall vê os pacotes desencriptados

Num túnel baseado em políticas, a firewall pode avaliar o pacote encriptado antes da desencriptação e o pacote desencriptado depois, em interfaces diferentes. Uma regra escrita para a interface errada está presente, correta e nunca corresponde. É assim que um conjunto de regras copiado de uma implementação funcional pode falhar em hardware idêntico.

O IPsec baseado em rotas e a maioria das implementações modernas apresentam uma interface de túnel, por isso o pacote desencriptado chega aí e aplicam-se as regras normais de interface. Confirme que modelo a implementação utiliza antes de copiar um conjunto de regras de um guia escrito para o outro. A interface de túnel é também o local a consultar quando precisa de saber se um pacote foi sequer desencriptado.

O encaminhamento assimétrico quebra a suposição

Uma firewall com estado assume que vê as duas metades da conversa. Se a resposta regressar por outro gateway, esse dispositivo não mantém estado para o pedido e descarta-a segundo a sua própria política. O sintoma é uma falha unidirecional que nenhuma regra do lado emissor consegue reparar. Siga o caminho da resposta antes de editar o que quer que seja.

Verifique a rota da resposta antes de adicionar uma regra ampla de autorização dos dois lados. Tolerar tudo em todas as interfaces esconde o erro de encaminhamento e alarga o acesso ao mesmo tempo, que é a pior combinação disponível.

Verifique ambos os sentidos com endereços de origem reais

Teste com o endereço que o lado remoto observa realmente, pois a tradução pode fazer com que uma regra de origem não corresponda a nada. Execute a captura nos dois gateways ao mesmo tempo.

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

Um pedido que aparece no gateway remoto com um endereço de origem inesperado explica uma regra que nunca corresponde, e uma resposta que chega à interface errada explica um desalinhamento de estado. Depois teste um destino dentro do âmbito aprovado e outro fora dele, para que o limite seja demonstrado em vez de assumido.

Registe o endereço de origem após a tradução, a interface utilizada pelo pacote desencriptado e a regra que correspondeu. Esses três factos respondem ao próximo ticket sem repetir toda a investigação.