Linux EHOSTUNREACH com OpenVPN: qual salto seguinte falhou?

O EHOSTUNREACH é uma decisão local tão frequentemente quanto uma falha remota. O núcleo pode rejeitar um pacote porque uma rota diz que o destino é inalcançável, porque o salto seguinte Ethernet nunca respondeu, ou porque chegou um relatório ICMP host-unreachable de mais adiante no caminho. Cada origem vive numa tabela ou cache diferente, e cada uma corrige-se num local diferente. Leia a rota selecionada e o estado do salto seguinte antes de tocar nas cifras ou reinstalar o túnel.

Escolha o endereço e o namespace que o cliente realmente usa

Comece por fixar o destino e o namespace de rede que produziu o erro. Um cliente VPN pode correr no seu próprio namespace, e uma consulta a partir do namespace predefinido consulta outra tabela de encaminhamento com regras de política diferentes.

A consulta deve usar o mesmo contexto de origem, marca e tabela que a aplicação que falha, ou pode responder a uma pergunta que ninguém fez. Para um par IPv4 ilustrativo, as verificações só de leitura são:

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

Um resultado de uma shell administrativa prova apenas o que essa shell faria. Se o cliente define uma marca de firewall ou se liga a uma VRF, repita a consulta com a marca correspondente ou dentro da VRF, e compare a rota selecionada e o salto seguinte. O primeiro endereço a confirmar é o endereço do par no perfil, não o cluster ou serviço que o utilizador nomeia.

Uma rota inalcançável explícita rejeita o pacote localmente

Uma rota do tipo unreachable é uma resposta local deliberada. Diz ao núcleo para descartar o pacote e devolver EHOSTUNREACH ao remetente, por isso o erro aparece instantaneamente e sem qualquer tráfego a sair da máquina. Alguém, ou alguma automatização, colocou essa rota ali de propósito.

Os tipos de rota não são intercambiáveis. O blackhole descarta o pacote sem erro ao remetente, o prohibit devolve EACCES e o unreachable devolve EHOSTUNREACH. Um auxiliar de VPN que instala uma rota sumidouro durante a reconexão pode, por isso, produzir uma rajada de erros host-unreachable que desaparecem quando o túnel sobe, enquanto uma rota blackhole produziria, em vez disso, tempos de espera silenciosos.

Procure o tipo em todas as tabelas antes de culpar o extremo remoto. A regra que seleciona a tabela importa tanto como a rota que contém, e uma rota adicionada à tabela principal não ajudará um cliente cuja regra de política envia o seu tráfego para outro sítio.

Um vizinho morto produz o mesmo erro em Ethernet

Quando a rota selecionada usa uma gateway on-link, a entrega precisa de um endereço de camada de ligação resolvido. O núcleo envia um pedido de vizinho ARP ou IPv6, e se não chegar resposta o pacote não pode ser enquadrado. O envio falha então com EHOSTUNREACH mesmo que a rota em si seja válida.

A tabela de vizinhos nomeia a etapa. INCOMPLETE significa que uma resolução ainda está em curso, FAILED significa que a última tentativa não obteve resposta, e REACHABLE ou STALE significa que o núcleo tem um endereço utilizável. Uma entrada FAILED para a gateway VPN é um problema de entrega local, não uma prova sobre o lado remoto do túnel.

Leia a entrada para o salto seguinte real, não para o endereço de internet remoto. Um endereço remoto é normalmente alcançado através de um router, pelo que não terá o seu próprio registo ARP; pedir um é um erro de categoria que envia as pessoas à procura de uma entrada ausente que nunca deveria ter existido.

Relatórios remotos e erros UDP assíncronos

O EHOSTUNREACH também pode chegar de fora. Um router que não consegue encaminhar o pacote pode enviar ICMP host unreachable, e o núcleo passa esse relatório ao socket que possui o fluxo. Nesse caso a rota e o vizinho estão bem, e a falha pertence a um salto além da rede local.

O UDP torna a atribuição mais difícil. Um erro devolvido por uma chamada posterior de envio ou receção pode referir-se a um datagrama anterior, pelo que o endereço e a hora da chamada que falha podem não corresponder ao pacote que desencadeou o relatório. Um socket UDP ligado recebe o erro uma vez, e um socket não ligado pode nunca vê-lo.

Por isso o momento pertence à evidência. Anote quando o erro apareceu, que endereço de par o socket usou e se o túnel tinha acabado de se reconectar. Uma rajada logo após uma mudança de rota aponta para a tabela local; um erro isolado minutos dentro de um fluxo estável aponta para um relatório de caminho.

Separe as camadas antes de mudar a criptografia

Três perguntas classificam o erro. O núcleo escolheu uma rota que rejeita o destino? Escolheu uma rota válida mas não resolveu o salto seguinte? Ou chegou um relatório de além da rede local? Só o terceiro caso pode envolver o extremo remoto do túnel, e mesmo assim não envolve a cifra.

Os problemas de autenticação e negociação surgem como erros próprios depois de o transporte atingir o par. Mudar uma cifra ou reinstalar o cliente não consegue corrigir uma rota unreachable local, e destrói as provas de rota e vizinho de que precisaria para a causa real.

Registe o destino, o namespace, a tabela selecionada, o salto seguinte, o estado do vizinho e a hora do erro antes da primeira alteração. Execute novamente a mesma consulta após a correção; uma rota que agora aponta para o túnel e uma entrada de vizinho que agora se resolve são uma prova mais forte do que um ping bem-sucedido a um endereço não relacionado.