Ping através de uma VPN: por que as regras de resposta de eco perdem o caminho de volta

Faça ping a um host através de uma VPN e o pedido sai com um tipo ICMP e volta com outro, o que basta para confundir qualquer regra escrita em termos de portas. Não existe porta de serviço de destino num intercâmbio de eco para copiar para a regra de retorno, e um filtro que espera simetria descartará a resposta enquanto o pedido passa sem obstáculos. A correção começa por ler o pacote tal como ele é e depois decidir qual fronteira do caminho toma a decisão. Normalmente trabalham duas camadas enquanto a terceira descarta a resposta em silêncio. As secções seguintes separam-nas pela ordem em que um pacote as encontra.

O pacote muda de tipo, não de porta

Um pedido de eco é ICMP de tipo 8, código 0, e transporta um identificador e um número de sequência. A resposta é de tipo 0, código 0, com o mesmo identificador e a mesma sequência, e os extremos IP trocados. A RFC 792 define esses campos, e o identificador é o que permite a um emissor emparelhar as respostas com os seus próprios pedidos.

O que falta é igualmente importante: não há cabeçalho TCP nem UDP, por isso não há porta a permitir. Uma regra que nomeia uma porta para uma resposta de eco descreve um pacote que nunca existirá. É o erro mais comum nos pedidos de ping por VPN. A regra parece específica, não se aplica a nada e deixa a falha exatamente onde estava.

Três contextos decidem o pacote

Se o ping aponta para um host da LAN remota, a passagem tem de ser encaminhada pela gateway. Se aponta para um endereço que pertence à própria gateway, termina no caminho de entrada local. Se é a gateway que origina o ping, o pacote começa no seu próprio caminho de saída e nunca atravessa a decisão de encaminhamento.

Estes três contextos têm cadeias de regras e contadores diferentes, e tratá-los como um só é a razão pela qual «a firewall permite ICMP» ainda pode produzir um ping falhado. O túnel exterior é um quarto contexto: permitir o ouvinte da VPN não permite automaticamente o pedido interno desencapsulado, e uma permissão interna não diz nada sobre se o túnel exterior está ativo.

Os filtros com estado e sem estado tratam a resposta de forma diferente

Uma firewall com estado que viu o pedido sair pode associar a resposta a esse fluxo e admiti-la sem uma segunda regra. Um filtro sem estado não tem essa memória, por isso a direção de retorno precisa da sua própria autorização explícita, com a origem e o destino invertidos.

Verifique que modelo o produto implementa realmente antes de escrever o que quer que seja. Uma regra para o pedido de eco não cobre necessariamente a resposta de eco, e um produto que segue consultas ICMP pode ainda aplicar outra política às respostas que chegam por outra interface.

Limite o que permite. Permitir todas as respostas de eco de qualquer lugar não é o mesmo que completar uma associação com estado, e um número de tipo não autentica o emissor.

A tradução também muda o identificador

Se a tradução de origem for intencional, o tuplo no extremo remoto não corresponde ao que o cliente enviou. Um NAT pode traduzir o identificador da consulta ICMP juntamente com os endereços, por isso insistir que o mesmo número apareça nos dois lados produz uma discrepância falsa.

Em vez disso, correlacione o mapeamento que o tradutor comunica. Um tradutor que reescreve o identificador não preservará o número que o seu cliente registou, por isso trate o mapeamento como a identidade e não o número. Depois siga um pedido identificável pelo caminho: confirme que chega ao destino com a origem esperada, confirme que o destino emitiu uma resposta, siga a rota dessa resposta de volta, e confirme que o cliente a recebeu em vez de apenas ver um contador da gateway subir.

Não junte os erros ICMP à política de eco

A mensagem «é necessária fragmentação» usada pela descoberta de MTU do caminho não é uma resposta de eco, e a sua carga útil cita o pacote que a desencadeou. Uma autorização apenas para eco que descarta silenciosamente esses erros transforma um problema de tamanho numa ligação pendurada, que é o contrário de útil.

A mesma cautela aplica-se às famílias de endereços. O ICMPv6 usa tipos de mensagem diferentes e transporta funções essenciais que o IPv4 não tem, por isso copiar estes números para uma regra IPv6 é simplesmente errado.

Quando o intercâmbio de eco funcionar, teste a aplicação real em separado. Um ping bem-sucedido prova a ida e volta de um protocolo, a um tamanho e a um destino, e não é uma licença para assumir que HTTPS, SMB ou qualquer outro fluxo está permitido.