Linux EHOSTUNREACH con OpenVPN: que salto seguinte fallou?

EHOSTUNREACH é unha decisión local tan a miúdo como un fallo remoto. O núcleo pode rexeitar un paquete porque unha ruta di que o destino é inalcanzable, porque o seguinte salto Ethernet nunca respondeu ou porque chegou un informe ICMP host-unreachable desde máis adiante na ruta. Cada orixe vive nunha táboa ou caché distinta, e cada unha corríxese nun lugar distinto. Lea a ruta seleccionada e o estado do seguinte salto antes de tocar cifrados ou reinstalar o túnel.

Escolla o enderezo e o namespace que o cliente usa realmente

Comece fixando o destino e o namespace de rede que produciu o erro. Un cliente VPN pode executarse no seu propio namespace, e unha consulta desde o namespace predeterminado consulta outra táboa de enrutamento con regras de política distintas.

A consulta debe usar o mesmo contexto de orixe, marca e táboa que a aplicación que falla, ou pode responder unha pregunta que ninguén fixo. Para un par IPv4 ilustrativo, as comprobacións de só lectura son:

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

Un resultado dunha shell administrativa só demostra que faría esa shell. Se o cliente estabelece unha marca de devasas ou se liga a unha VRF, repita a consulta coa marca correspondente ou dentro da VRF, e compare a ruta seleccionada e o seguinte salto. O primeiro enderezo que hai que confirmar é o do par no perfil, non o clúster ou servizo que nomea o usuario.

Unha ruta inalcanzable explícita rexeita o paquete localmente

Unha ruta de tipo unreachable é unha resposta local deliberada. Dille ao núcleo que descarte o paquete e devolva EHOSTUNREACH ao remitente, por iso o erro aparece ao instante e sen ningún tráfico que saia da máquina. Alguén, ou algunha automatización, puxo esa ruta alí a propósito.

Os tipos de ruta non son intercambiables. Blackhole descarta o paquete sen erro ao remitente, prohibit devolve EACCES e unreachable devolve EHOSTUNREACH. Un auxiliar de VPN que instala unha ruta sumidoiro durante a reconexión pode, por tanto, producir unha ráfaga de erros host-unreachable que desaparecen cando o túnel sobe, mentres que unha ruta blackhole produciría tempos de espera silenciosos no seu lugar.

Busque o tipo en todas as táboas antes de culpar o extremo remoto. A regra que selecciona a táboa importa tanto como a ruta que contén, e unha ruta engadida á táboa principal non axudará a un cliente cuxa regra de política envía o seu tráfico a outro sitio.

Un veciño morto produce o mesmo erro en Ethernet

Cando a ruta seleccionada usa unha porta de enlace no enlace, a entrega necesita un enderezo de capa de enlace resolto. O núcleo envía unha solicitude de veciño ARP ou IPv6, e se non chega resposta o paquete non se pode encadrar. O envío falla entón con EHOSTUNREACH aínda que a ruta en si sexa válida.

A táboa de veciños nomea a etapa. INCOMPLETE significa que unha resolución aínda está en curso, FAILED significa que o último intento non obtivo resposta, e REACHABLE ou STALE significa que o núcleo ten un enderezo utilizábel. Unha entrada FAILED para a porta de enlace VPN é un problema de entrega local, non unha proba sobre o lado afastado do túnel.

Lea a entrada do seguinte salto real, non a do enderezo de internet remoto. Un enderezo remoto normalmente alcanzase a través dun router, así que non terá o seu propio rexistro ARP; pedir un é un erro de categoría que envía a xente a buscar unha entrada ausente que nunca debería existir.

Informes remotos e erros UDP asíncronos

EHOSTUNREACH tamén pode chegar de fóra. Un router que non pode reenviar o paquete pode enviar ICMP host unreachable, e o núcleo pasa ese informe ao socket que posúe o fluxo. Nese caso a ruta e o veciño están ben, e o fallo pertence a un salto máis alá da rede local.

UDP dificulta a atribución. Un erro devolto por unha chamada posterior de envío ou recepción pode referirse a un datagrama anterior, así que o enderezo e a hora da chamada que falla poden non coincidir co paquete que desencadeou o informe. Un socket UDP conectado recibe o erro unha vez, e un socket non conectado pode non velo nunca.

Por iso o momento pertence á evidencia. Anote cando apareceu o erro, que enderezo de par usou o socket e se o túnel acababa de reconectarse. Unha ráfaga xusto despois dun cambio de ruta apunta á táboa local; un erro illado minutos dentro dun fluxo estable apunta a un informe de ruta.

Separe as capas antes de cambiar a criptografía

Tres preguntas clasifican o erro. ¿Escolleu o núcleo unha ruta que rexeita o destino? ¿Escolleu unha ruta válida pero non resolveu o seguinte salto? ¿Ou chegou un informe desde máis alá da rede local? Só o terceiro caso pode implicar o extremo afastado do túnel, e aínda así non implica o cifrado.

Os problemas de autenticación e negociación aparecen como erros propios despois de que o transporte chega ao par. Cambiar un cifrado ou reinstalar o cliente non pode arranxar unha ruta unreachable local, e destrúe a evidencia de ruta e veciño que necesitaría para a causa real.

Rexistre o destino, o namespace, a táboa seleccionada, o seguinte salto, o estado do veciño e a hora do erro antes do primeiro cambio. Volva executar a mesma consulta tras a corrección; unha ruta que agora apunta ao túnel e unha entrada de veciño que agora se resolve son unha proba máis forte que un ping correcto a un enderezo non relacionado.