Linux EHOSTUNREACH med OpenVPN: hvilket næste hop fejlede?

EHOSTUNREACH er lige så ofte en lokal beslutning som en fjern fejl. Kernen kan afvise en pakke, fordi en rute siger, at destinationen er unreachable, fordi Ethernet-næstehop aldrig svarede, eller fordi en ICMP host-unreachable-rapport ankom længere fremme på stien. Hver kilde lever i en anden tabel eller cache, og hver enkelt rettes et andet sted. Læs den valgte rute og næstehoppets tilstand, før du rører cifre eller geninstallerer tunnelen.

Vælg den adresse og det namespace, klienten faktisk bruger

Begynd med at fastlåse destinationen og det netværks-namespace, der producerede fejlen. En VPN-klient kan køre i sit eget namespace, og et opslag fra standard-namespaceet konsulterer en anden routingtabel med andre politikregler.

Opslaget skal bruge samme kilde-, mark- og tabelkontekst som det fejlende program, ellers svarer det måske på et spørgsmål, ingen stillede. For en illustrativ IPv4-peer er kun-læs-kontrollerne:

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

Et resultat fra en administrativ shell beviser kun, hvad den shell ville gøre. Hvis klienten sætter et firewall-mark eller binder til en VRF, gentag opslaget med det matchende mark eller inde i VRF'en, og sammenlign den valgte rute og det næste hop. Den første adresse, der skal bekræftes, er peer-adressen i profilen, ikke det cluster eller den tjeneste, brugeren nævner.

En eksplicit unreachable-rute afviser pakken lokalt

En rute af typen unreachable er et bevidst lokalt svar. Den fortæller kernen at kassere pakken og returnere EHOSTUNREACH til afsenderen, og derfor vises fejlen øjeblikkeligt og uden trafik, der forlader maskinen. Nogen, eller en automatisering, satte den rute der med vilje.

Rutetyperne kan ikke udskiftes. Blackhole kasserer pakken uden fejl til afsenderen, prohibit returnerer EACCES, og unreachable returnerer EHOSTUNREACH. En VPN-hjælper, der installerer en sink-rute under genopkobling, kan derfor give en byge af host-unreachable-fejl, der forsvinder, når tunnelen er oppe, mens en blackhole-rute i stedet ville give stille timeouts.

Gennemsøg alle tabeller for typen, før du bebrejder den fjerne ende. Reglen, der vælger tabellen, betyder lige så meget som ruten i den, og en rute tilføjet hovedtabellen hjælper ikke en klient, hvis politikregel sender dens trafik et andet sted hen.

En død nabo giver den samme fejl på Ethernet

Når den valgte rute bruger en on-link-gateway, kræver levering en opløst linklagsadresse. Kernen sender en ARP- eller IPv6-naboanmodning, og hvis der ikke kommer svar, kan pakken ikke indrammes. Sendingen fejler derefter med EHOSTUNREACH, selv om ruten selv er gyldig.

Nabotabellen angiver fasen. INCOMPLETE betyder, at en opløsning stadig er i gang, FAILED betyder, at det sidste forsøg ikke fik svar, og REACHABLE eller STALE betyder, at kernen har en brugbar adresse. En FAILED-post for VPN-gatewayen er et lokalt leveringsproblem, ikke bevis om tunnelens fjerne side.

Læs posten for det faktiske næste hop, ikke for den fjerne internetadresse. En fjern adresse nås normalt via en router, så den har ikke sin egen ARP-post; at spørge efter en er en kategorifejl, der sender folk på jagt efter en manglende post, som aldrig burde have eksisteret.

Fjerne rapporter og asynkrone UDP-fejl

EHOSTUNREACH kan også komme udefra. En router, der ikke kan videresende pakken, sender måske ICMP host unreachable, og kernen giver den rapport videre til den socket, der ejer flowet. I det tilfælde er ruten og naboen i orden, og fejlen hører til et hop uden for det lokale netværk.

UDP gør tilskrivningen sværere. En fejl, der returneres af et senere send- eller receive-kald, kan referere til et tidligere datagram, så adressen og tidspunktet for det fejlende kald passer måske ikke til den pakke, der udløste rapporten. En forbundet UDP-socket modtager fejlen én gang, og en uforbundet socket ser den måske aldrig.

Derfor hører timing med i beviset. Noter, hvornår fejlen dukkede op, hvilken peer-adresse socket'en brugte, og om tunnelen lige var genopkoblet. En byge lige efter en ruteændring peger på den lokale tabel; en enkelt fejl minutter inde i et stabilt flow peger på en stirapport.

Adskil lagene, før du ændrer krypto

Tre spørgsmål klassificerer fejlen. Valgte kernen en rute, der afviser destinationen? Valgte den en gyldig rute, men kunne ikke opløse det næste hop? Eller ankom en rapport fra uden for det lokale netværk? Kun det tredje tilfælde kan involvere tunnelens fjerne ende, og selv da ikke krypteringen.

Problemer med godkendelse og forhandling viser sig som deres egne fejl, efter transporten når peeren. At ændre en cipher eller geninstallere klienten kan ikke rette en lokal unreachable-rute, og det ødelægger de rute- og nabobeviser, du ville have brug for til den virkelige årsag.

Registrer destination, namespace, valgt tabel, næste hop, nabostatus og fejltidspunkt før den første ændring. Kør det samme opslag igen efter rettelsen; en rute, der nu peger på tunnelen, og en nabopost, der nu opløses, er stærkere bevis end et vellykket ping til en uvedkommende adresse.