Linux EHOSTUNREACH con OpenVPN: quale salto successivo ha fallito?

EHOSTUNREACH è una decisione locale tanto spesso quanto un guasto remoto. Il kernel può rifiutare un pacchetto perché una rotta dice che la destinazione è irraggiungibile, perché il salto successivo Ethernet non ha mai risposto, o perché è arrivato un rapporto ICMP host-unreachable da più avanti lungo il percorso. Ogni origine vive in una tabella o cache diversa, e ognuna si corregge in un punto diverso. Leggi la rotta selezionata e lo stato del salto successivo prima di toccare i cifrari o reinstallare il tunnel.

Scegli l’indirizzo e il namespace che il client usa davvero

Inizia fissando la destinazione e il namespace di rete che ha prodotto l’errore. Un client VPN può girare nel proprio namespace, e una ricerca dal namespace predefinito consulta un’altra tabella di routing con regole di policy diverse.

La ricerca deve usare lo stesso contesto di origine, marca e tabella dell’applicazione che fallisce, altrimenti potrebbe rispondere a una domanda che nessuno ha posto. Per un peer IPv4 illustrativo, i controlli in sola lettura sono:

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 risultato da una shell amministrativa dimostra solo ciò che quella shell farebbe. Se il client imposta una marca firewall o si lega a una VRF, ripeti la ricerca con la marca corrispondente o dentro la VRF, e confronta la rotta selezionata e il salto successivo. Il primo indirizzo da confermare è quello del peer nel profilo, non il cluster o il servizio che l’utente nomina.

Una rotta irraggiungibile esplicita rifiuta il pacchetto localmente

Una rotta di tipo unreachable è una risposta locale deliberata. Dice al kernel di scartare il pacchetto e restituire EHOSTUNREACH al mittente, ed è per questo che l’errore appare all’istante e senza che alcun traffico lasci la macchina. Qualcuno, o qualche automazione, ha messo quella rotta lì di proposito.

I tipi di rotta non sono intercambiabili. Blackhole scarta il pacchetto senza errore al mittente, prohibit restituisce EACCES e unreachable restituisce EHOSTUNREACH. Un helper VPN che installa una rotta di scarto durante la riconnessione può quindi produrre una raffica di errori host-unreachable che scompaiono quando il tunnel sale, mentre una rotta blackhole produrrebbe invece timeout silenziosi.

Cerca il tipo in tutte le tabelle prima di dare la colpa all’estremo remoto. La regola che seleziona la tabella conta quanto la rotta al suo interno, e una rotta aggiunta alla tabella principale non aiuterà un client la cui regola di policy manda il suo traffico altrove.

Un vicino morto produce lo stesso errore su Ethernet

Quando la rotta selezionata usa un gateway on-link, la consegna richiede un indirizzo di livello collegamento risolto. Il kernel invia una richiesta di vicino ARP o IPv6, e se non arriva risposta il pacchetto non può essere incapsulato. L’invio fallisce allora con EHOSTUNREACH anche se la rotta stessa è valida.

La tabella dei vicini nomina la fase. INCOMPLETE significa che una risoluzione è ancora in corso, FAILED significa che l’ultimo tentativo non ha ricevuto risposta, e REACHABLE o STALE significa che il kernel ha un indirizzo utilizzabile. Una voce FAILED per il gateway VPN è un problema di consegna locale, non una prova sul lato remoto del tunnel.

Leggi la voce per il salto successivo reale, non per l’indirizzo internet remoto. Un indirizzo remoto si raggiunge di solito tramite un router, quindi non avrà un proprio record ARP; chiederne uno è un errore di categoria che manda le persone a cercare una voce mancante che non sarebbe mai dovuta esistere.

Rapporti remoti ed errori UDP asincroni

EHOSTUNREACH può anche arrivare dall’esterno. Un router che non può inoltrare il pacchetto può inviare ICMP host unreachable, e il kernel passa quel rapporto al socket che possiede il flusso. In quel caso la rotta e il vicino sono a posto, e il guasto appartiene a un salto oltre la rete locale.

UDP rende l’attribuzione più difficile. Un errore restituito da una chiamata di invio o ricezione successiva può riferirsi a un datagramma precedente, quindi l’indirizzo e l’ora della chiamata che fallisce potrebbero non corrispondere al pacchetto che ha innescato il rapporto. Un socket UDP connesso riceve l’errore una volta, e un socket non connesso potrebbe non vederlo mai.

Per questo il momento fa parte delle prove. Annota quando è apparso l’errore, quale indirizzo peer usava il socket e se il tunnel si era appena riconnesso. Una raffica subito dopo un cambio di rotta punta alla tabella locale; un errore isolato dopo qualche minuto di flusso stabile punta a un rapporto di percorso.

Separa i livelli prima di cambiare la crittografia

Tre domande classificano l’errore. Il kernel ha scelto una rotta che rifiuta la destinazione? Ha scelto una rotta valida ma non è riuscito a risolvere il salto successivo? O è arrivato un rapporto da oltre la rete locale? Solo il terzo caso può coinvolgere l’estremo remoto del tunnel, e anche allora non coinvolge la crittografia.

I problemi di autenticazione e negoziazione emergono come errori propri dopo che il trasporto raggiunge il peer. Cambiare un cifrario o reinstallare il client non può correggere una rotta unreachable locale, e distrugge le prove di rotta e vicino che servirebbero per la causa reale.

Registra destinazione, namespace, tabella selezionata, salto successivo, stato del vicino e ora dell’errore prima del primo cambiamento. Esegui di nuovo la stessa ricerca dopo la correzione; una rotta che ora punta al tunnel e una voce di vicino che ora si risolve sono una prova più forte di un ping riuscito a un indirizzo non correlato.