Porque é que uma resposta UDP do OpenVPN sai do endereço errado

Um cliente OpenVPN marca um endereço, o servidor responde a partir de outro e o túnel nunca sobe. O registo do servidor mostra o pacote a chegar e uma captura mostra a resposta a sair, pelo que a culpa é atribuída ao cliente. Num anfitrião com várias interfaces, ou com vários endereços numa só interface, as duas partes simplesmente não concordam sobre que endereço está em uso. A resposta é válida na camada IP, mas muitos clientes descartam um datagrama cuja origem não é o endereço que contactaram.

O que o cliente vê quando a origem muda

Um socket UDP que não está ligado a um endereço local concreto não tem origem fixa, por isso o núcleo escolhe uma no momento do envio. Essa escolha vem de uma consulta de rota para o endereço do cliente, e a origem passa a ser o endereço da interface que a consulta seleciona. Numa máquina com uma só interface a escolha é invisível; num anfitrião com um endereço de gestão, um endereço público e um endereço secundário na mesma placa de rede, depende das métricas e da política de encaminhamento. O encaminhamento por políticas torna a discrepância mais provável em vez de menos, porque uma regra pode selecionar uma ligação ascendente que o cliente nunca alcançou. Basta uma rota predefinida aprendida de um fornecedor mais uma regra de origem que aponte para outro.

Os clientes que filtram respostas, e o seguimento de ligações que espera o quádruplo exato e a origem, descartam a resposta sem uma mensagem útil. O túnel expira então como se nada tivesse chegado, e é por isso que isto é confundido com um problema de firewall do lado do cliente. Uma captura feita apenas no servidor confirma o erro em vez de o explicar, porque a resposta sai mesmo. Compare a origem da resposta com o endereço que o cliente marcou antes de alterar qualquer outra coisa.

O que a opção multihome faz realmente

A diretiva escreve-se multihome num ficheiro de configuração e --multihome na linha de comandos, e faz com que um servidor UDP responda a partir do endereço que o pacote do cliente alcançou. O núcleo entrega o endereço de destino original como dados auxiliares na receção, e o OpenVPN usa esse valor como origem da resposta. Assim, um servidor à escuta num endereço universal, local 0.0.0.0 para IPv4 ou o seu equivalente IPv6, comporta-se como se cada cliente tivesse alcançado um ouvinte dedicado. Os clientes que entraram pelo endereço público recebem respostas do endereço público, e os clientes num endereço interno recebem-nas desse endereço. Mais nada no caminho do pacote se move: a rota, as regras de filtro e a configuração do túnel ficam exatamente como estavam.

É precisamente esta última propriedade que torna a opção segura de acrescentar a um servidor que já funciona, e é também a razão pela qual não consegue reparar um filtro que só permite um endereço. O pacote continua a ter de ser aceite no caminho que segue, por isso a correção da origem muda a proveniência da resposta e mais nada. Também é só para UDP: um ouvinte TCP não tem este problema na mesma forma, porque a ligação é identificada pelo quádruplo e não pelo endereço de origem da resposta.

Quando um endereço local fixo é a predefinição errada

Antes de recorrer à opção, verifique se o servidor liga um endereço local concreto, porque um ouvinte ligado responde sempre a partir desse endereço. Isso está correto para uma implementação com uma só interface e errado assim que os clientes usam legitimamente mais do que um endereço. Se a ligação foi deliberada, decida se o servidor deve aceitar tráfego em endereços adicionais. Retirar a ligação aumenta a exposição, por isso as interfaces e as redes de origem permitidas têm de ser impostas pelo serviço e pelo filtro, não apenas pelo endereço de ligação.

A referência do OpenVPN limita a opção a servidores UDP, assinala o processamento adicional no caminho do pacote e regista quais plataformas a suportam. Confirme-o na versão instalada antes de planear com base nisso. Onde não é suportada, a alternativa é ligar o endereço específico ou corrigir o encaminhamento de retorno, e ambas são alterações mais estreitas do que parecem à primeira vista. Escutar em universal também tem consequências além das respostas: um servidor em todos os endereços é alcançável a partir de cada rede a que o anfitrião está ligado, e essa pode não ser a exposição que alguém pretendia.

Prove a origem da resposta a partir de fora

Teste a partir de fora do servidor e registe o endereço e o transporte exatos que o cliente usou antes de capturar seja o que for. As três sondagens abaixo respondem a três perguntas diferentes, e a ordem é importante.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

A captura mostra o endereço de origem na resposta, e é esse o facto em que todo o artigo assenta. A lista de sockets mostra o que o servidor ligou realmente, porque um ouvinte universal e um concreto parecem idênticos num ficheiro de configuração e comportam-se de forma diferente na rede. A consulta de rota mostra a origem que o núcleo escolheria para esse fluxo, e isso explica a captura antes de alterar seja o que for. Repita as três para IPv4 e IPv6 em separado, porque são ouvintes separados e consultas separadas, e uma entrada universal para uma família não diz nada sobre a outra.

Encaminhamento, descoberta e filtragem continuam separados

Preservar a origem da resposta não instala uma rota de saída, não atualiza o DNS dinâmico nem faz com que uma família de endereços aceite a outra. Num servidor com várias ligações ascendentes, o caminho de retorno de cada origem tem de ser acordado deliberadamente, senão as respostas saem por uma interface que o filtro do cliente nunca permitiu. Do mesmo modo, um novo endereço após uma mudança de prefixo tem de chegar aos clientes através da descoberta e do fluxo de reconexão suportado, e não através do registo antigo.

Deixe as verificações de identidade do servidor e a validação de certificados exatamente como estão, porque um endereço alterado não justifica aceitar um par não verificado. Se a resposta agora sai da origem prevista e o túnel continua a falhar, considere o problema da origem resolvido e siga em frente. O erro seguinte observado pertence ao encaminhamento, à filtragem ou à autenticação, e voltar a mudar o ouvinte não chegará lá. Escreva a origem da resposta no ticket ao lado do endereço que o cliente marcou, para que a pessoa seguinte possa verificar o mesmo facto com um único comando.