Linux EHOSTUNREACH cu OpenVPN: care salt următor a eșuat?

EHOSTUNREACH este o decizie locală la fel de des ca o defecțiune îndepărtată. Nucleul poate respinge un pachet pentru că o rută spune că destinația este inaccesibilă, pentru că următorul salt Ethernet nu a răspuns niciodată, sau pentru că a sosit un raport ICMP host-unreachable de mai departe pe traseu. Fiecare sursă trăiește într-un tabel sau cache diferit, iar fiecare se remediază într-un loc diferit. Citiți ruta selectată și starea următorului salt înainte de a atinge cifrurile sau de a reinstala tunelul.

Alegeți adresa și spațiul de nume pe care clientul le folosește efectiv

Începeți prin a fixa destinația și spațiul de nume de rețea care au produs eroarea. Un client VPN poate rula în propriul spațiu de nume, iar o căutare din spațiul de nume implicit consultă un alt tabel de rutare cu alte reguli de politică.

Căutarea trebuie să folosească același context de sursă, marcaj și tabel ca aplicația care eșuează, altfel poate răspunde la o întrebare pe care nimeni nu a pus-o. Pentru un peer IPv4 ilustrativ, verificările doar-citire sunt:

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 rezultat dintr-un shell administrativ dovedește doar ce ar face acel shell. Dacă clientul setează un marcaj de firewall sau se leagă de un VRF, repetați căutarea cu marcajul corespunzător sau în interiorul VRF-ului, și comparați ruta selectată și saltul următor. Prima adresă de confirmat este adresa peer-ului din profil, nu clusterul sau serviciul pe care îl numește utilizatorul.

O rută inaccesibilă explicită respinge pachetul local

O rută de tip unreachable este un răspuns local deliberat. Îi spune nucleului să arunce pachetul și să returneze EHOSTUNREACH expeditorului, de aceea eroarea apare instantaneu și fără niciun trafic care să părăsească mașina. Cineva, sau o automatizare, a pus acea rută acolo intenționat.

Tipurile de rută nu sunt interschimbabile. Blackhole aruncă pachetul fără eroare către expeditor, prohibit returnează EACCES, iar unreachable returnează EHOSTUNREACH. Un ajutor VPN care instalează o rută de scurgere în timpul reconectării poate produce astfel un val de erori host-unreachable care dispar când tunelul se ridică, în timp ce o rută blackhole ar produce în schimb expirări silențioase.

Căutați tipul în toate tabelele înainte de a învinui capătul îndepărtat. Regula care selectează tabelul contează la fel de mult ca ruta din el, iar o rută adăugată în tabelul principal nu va ajuta un client a cărui regulă de politică îi trimite traficul în altă parte.

Un vecin mort produce aceeași eroare pe Ethernet

Când ruta selectată folosește o poartă on-link, livrarea are nevoie de o adresă de nivel de legătură rezolvată. Nucleul trimite o cerere de vecin ARP sau IPv6, iar dacă nu sosește niciun răspuns pachetul nu poate fi încadrat. Trimiterea eșuează atunci cu EHOSTUNREACH chiar dacă ruta în sine este validă.

Tabelul vecinilor numește etapa. INCOMPLETE înseamnă că o rezolvare este încă în curs, FAILED înseamnă că ultima încercare nu a primit răspuns, iar REACHABLE sau STALE înseamnă că nucleul are o adresă utilizabilă. O intrare FAILED pentru poarta VPN este o problemă de livrare locală, nu o dovadă despre partea îndepărtată a tunelului.

Citiți intrarea pentru următorul salt real, nu pentru adresa de internet îndepărtată. O adresă îndepărtată este de obicei atinsă printr-un router, deci nu va avea propriul record ARP; a cere unul este o eroare de categorie care trimite oamenii să caute o intrare lipsă care nu ar fi trebuit să existe niciodată.

Rapoarte îndepărtate și erori UDP asincrone

EHOSTUNREACH poate veni și din exterior. Un router care nu poate înainta pachetul poate trimite ICMP host unreachable, iar nucleul transmite acel raport socketului care deține fluxul. În acest caz ruta și vecinul sunt în regulă, iar defecțiunea aparține unui salt dincolo de rețeaua locală.

UDP face atribuirea mai dificilă. O eroare returnată de un apel send sau receive ulterior se poate referi la un datagram anterior, astfel încât adresa și momentul apelului care eșuează pot să nu corespundă pachetului care a declanșat raportul. Un socket UDP conectat primește eroarea o dată, iar un socket neconectat poate să nu o vadă niciodată.

De aceea momentul face parte din dovezi. Notați când a apărut eroarea, ce adresă de peer a folosit socketul și dacă tunelul tocmai se reconectase. Un val imediat după o schimbare de rută indică tabelul local; o singură eroare după câteva minute într-un flux stabil indică un raport de traseu.

Separați straturile înainte de a schimba criptografia

Trei întrebări clasifică eroarea. Nucleul a ales o rută care respinge destinația? A ales o rută validă, dar nu a reușit să rezolve saltul următor? Sau a sosit un raport de dincolo de rețeaua locală? Doar al treilea caz poate implica capătul îndepărtat al tunelului, și chiar atunci nu implică criptarea.

Problemele de autentificare și negociere apar ca erori proprii după ce transportul ajunge la peer. Schimbarea unui cifru sau reinstalarea clientului nu poate repara o rută unreachable locală și distruge dovezile de rută și vecin de care ați avea nevoie pentru cauza reală.

Înregistrați destinația, spațiul de nume, tabelul selectat, saltul următor, starea vecinului și momentul erorii înainte de prima schimbare. Rulați din nou aceeași căutare după corectare; o rută care acum indică tunelul și o intrare de vecin care acum se rezolvă sunt o dovadă mai puternică decât un ping reușit către o adresă nelegată.