Linux EHOSTUNREACH amb OpenVPN: quin salt següent ha fallat?

EHOSTUNREACH és una decisió local tan sovint com una fallada remota. El nucli pot rebutjar un paquet perquè una ruta diu que la destinació és inabastable, perquè el salt següent d’Ethernet no va respondre mai o perquè va arribar un informe ICMP host-unreachable des de més enllà al llarg del camí. Cada origen viu en una taula o memòria cau diferent, i cada un es corregeix en un lloc diferent. Llegiu la ruta seleccionada i l’estat del salt següent abans de tocar els xifrats o reinstal·lar el túnel.

Trieu l’adreça i l’espai de noms que el client fa servir realment

Comenceu fixant la destinació i l’espai de noms de xarxa que va produir l’error. Un client VPN pot córrer en el seu propi espai de noms, i una consulta des de l’espai de noms per defecte consulta una taula d’encaminament diferent amb regles de política diferents.

La consulta ha d’usar el mateix context d’origen, marca i taula que l’aplicació que falla, o pot respondre una pregunta que ningú no ha fet. Per a un parell IPv4 il·lustratiu, les comprovacions només de lectura són:

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 resultat d’una shell administrativa només demostra què faria aquella shell. Si el client estableix una marca de tallafocs o s’enllaça a una VRF, repetiu la consulta amb la marca corresponent o dins de la VRF, i compareu la ruta seleccionada i el salt següent. La primera adreça a confirmar és l’adreça del parell al perfil, no el clúster o servei que l’usuari anomena.

Una ruta inabastable explícita rebutja el paquet localment

Una ruta de tipus unreachable és una resposta local deliberada. Diu al nucli que descarti el paquet i retorni EHOSTUNREACH al remitent, i per això l’error apareix a l’instant i sense cap trànsit que surti de la màquina. Algú, o alguna automatització, va posar aquesta ruta allà a propòsit.

Els tipus de ruta no són intercanviables. Blackhole descarta el paquet sense error al remitent, prohibit retorna EACCES i unreachable retorna EHOSTUNREACH. Un auxiliar de VPN que instal·la una ruta d’embornal durant la reconnexió pot, per tant, produir una ràfega d’errors host-unreachable que desapareixen quan el túnel puja, mentre que una ruta blackhole produiria temps d’espera silenciosos en lloc seu.

Cerqueu el tipus a totes les taules abans de culpar l’extrem remot. La regla que selecciona la taula importa tant com la ruta que hi ha dins, i una ruta afegida a la taula principal no ajudarà un client la regla de política del qual envia el seu trànsit a un altre lloc.

Un veí mort produeix el mateix error a Ethernet

Quan la ruta seleccionada usa una porta d’enllaç en línia, el lliurament necessita una adreça de capa d’enllaç resolta. El nucli envia una sol·licitud de veí ARP o IPv6, i si no arriba cap resposta el paquet no es pot emmarcar. L’enviament falla llavors amb EHOSTUNREACH tot i que la ruta mateixa és vàlida.

La taula de veïns nomena l’etapa. INCOMPLETE vol dir que una resolució encara està en curs, FAILED vol dir que l’últim intent no va obtenir resposta, i REACHABLE o STALE vol dir que el nucli té una adreça utilitzable. Una entrada FAILED per a la porta d’enllaç VPN és un problema de lliurament local, no una prova sobre el costat llunyà del túnel.

Llegiu l’entrada del salt següent real, no la de l’adreça d’internet remota. Una adreça remota normalment s’assoleix a través d’un encaminador, així que no tindrà el seu propi registre ARP; demanar-ne un és un error de categoria que fa que la gent busqui una entrada absent que mai no havia d’existir.

Informes remots i errors UDP asíncrons

EHOSTUNREACH també pot arribar de fora. Un encaminador que no pot reenviar el paquet pot enviar ICMP host unreachable, i el nucli passa aquest informe al sòcol que posseeix el flux. En aquest cas la ruta i el veí estan bé, i la fallada pertany a un salt més enllà de la xarxa local.

UDP fa més difícil l’atribució. Un error retornat per una crida d’enviament o recepció posterior pot referir-se a un datagrama anterior, així que l’adreça i l’hora de la crida que falla poden no coincidir amb el paquet que va desencadenar l’informe. Un sòcol UDP connectat rep l’error una vegada, i un sòcol no connectat potser no el veu mai.

Per això el moment pertany a l’evidència. Anoteu quan va aparèixer l’error, quina adreça de parell va usar el sòcol i si el túnel s’acabava de reconectar. Una ràfega just després d’un canvi de ruta apunta a la taula local; un error solitari minuts dins d’un flux estable apunta a un informe de camí.

Separeu les capes abans de canviar la criptografia

Tres preguntes classifiquen l’error. El nucli va triar una ruta que rebutja la destinació? Va triar una ruta vàlida però no va resoldre el salt següent? O va arribar un informe des de més enllà de la xarxa local? Només el tercer cas pot implicar l’extrem llunyà del túnel, i fins i tot llavors no implica el xifratge.

Els problemes d’autenticació i negociació es presenten com a errors propis després que el transport arribi al parell. Canviar un xifrat o reinstal·lar el client no pot arreglar una ruta unreachable local, i destrueix l’evidència de ruta i veí que necessitaríeu per a la causa real.

Registreu la destinació, l’espai de noms, la taula seleccionada, el salt següent, l’estat del veí i l’hora de l’error abans del primer canvi. Torneu a executar la mateixa consulta després de la correcció; una ruta que ara apunta al túnel i una entrada de veí que ara es resol són una prova més forta que un ping correcte a una adreça no relacionada.