Linux EHOSTUNREACH med OpenVPN: hvilket neste hopp mislyktes?

EHOSTUNREACH er like ofte en lokal beslutning som en fjern feil. Kjernen kan avvise en pakke fordi en rute sier at målet er utilgjengelig, fordi Ethernet-nestehoppet aldri svarte, eller fordi en ICMP host-unreachable-rapport ankom lenger fremme på stien. Hver kilde lever i en annen tabell eller hurtigbuffer, og hver enkelt rettes på et annet sted. Les den valgte ruten og nestehoppets tilstand før du rører chiffere eller reinstallerer tunnelen.

Velg adressen og navnerommet klienten faktisk bruker

Begynn med å feste målet og nettverksnavnerommet som produserte feilen. En VPN-klient kan kjøre i sitt eget navnerom, og et oppslag fra standardnavnerommet konsulterer en annen rutetabell med andre policyregler.

Oppslaget må bruke samme kilde-, mark- og tabellkontekst som programmet som feiler, ellers kan det svare på et spørsmål ingen stilte. For en illustrativ IPv4-peer er skrivebeskyttede kontroller:

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 bare hva den shellen ville gjort. Hvis klienten setter en brannmurmark eller binder til en VRF, gjenta oppslaget med samsvarende mark eller inne i VRF-en, og sammenlign den valgte ruten og neste hopp. Den første adressen som skal bekreftes, er peer-adressen i profilen, ikke klyngen eller tjenesten brukeren nevner.

En eksplisitt utilgjengelig rute avviser pakken lokalt

En rute av typen unreachable er et bevisst lokalt svar. Den ber kjernen kaste pakken og returnere EHOSTUNREACH til avsenderen, og derfor vises feilen umiddelbart og uten trafikk som forlater maskinen. Noen, eller en automatisering, satte den ruten der med vilje.

Rutetypene kan ikke byttes om. Blackhole kaster pakken uten feil til avsenderen, prohibit returnerer EACCES, og unreachable returnerer EHOSTUNREACH. En VPN-hjelper som installerer en slukrute under gjenoppkobling, kan derfor gi en byge av host-unreachable-feil som forsvinner når tunnelen er oppe, mens en blackhole-rute i stedet ville gi stille tidsavbrudd.

Søk gjennom alle tabeller etter typen før du klandrer den fjerne enden. Regelen som velger tabellen, betyr like mye som ruten i den, og en rute lagt til hovedtabellen hjelper ikke en klient hvis policyregel sender trafikken dens et annet sted.

En død nabo gir samme feil på Ethernet

Når den valgte ruten bruker en on-link-gateway, trenger leveringen en oppslått lenkelagsadresse. Kjernen sender en ARP- eller IPv6-naboforespørsel, og hvis det ikke kommer svar, kan pakken ikke rammes inn. Sendingen feiler da med EHOSTUNREACH selv om ruten selv er gyldig.

Nabotabellen navngir fasen. INCOMPLETE betyr at en oppslagning pågår, FAILED betyr at siste forsøk ikke fikk svar, og REACHABLE eller STALE betyr at kjernen har en brukbar adresse. En FAILED-oppføring for VPN-gatewayen er et lokalt leveringsproblem, ikke bevis om den fjerne siden av tunnelen.

Les oppføringen for det faktiske neste hoppet, ikke for den fjerne internettadressen. En fjern adresse nås vanligvis via en ruter, så den vil ikke ha sin egen ARP-oppføring; å spørre etter en er en kategorifeil som sender folk på jakt etter en manglende oppføring som aldri skulle ha eksistert.

Fjerne rapporter og asynkrone UDP-feil

EHOSTUNREACH kan også komme utenfra. En ruter som ikke kan videresende pakken, kan sende ICMP host unreachable, og kjernen gir den rapporten videre til sockelen som eier flyten. I så fall er ruten og naboen i orden, og feilen hører til et hopp utenfor det lokale nettverket.

UDP gjør tilskrivningen vanskeligere. En feil som returneres av et senere send- eller receive-kall, kan gjelde et tidligere datagram, så adressen og tidspunktet for det feilende kallet passer kanskje ikke til pakken som utløste rapporten. En tilkoblet UDP-sockel mottar feilen én gang, og en utilkoblet sockel ser den kanskje aldri.

Derfor hører timing med i beviset. Noter når feilen dukket opp, hvilken peer-adresse sockelen brukte, og om tunnelen nettopp var gjenoppkoblet. En byge rett etter en ruteendring peker på den lokale tabellen; en enkelt feil minutter inn i en stabil flyt peker på en stirapport.

Skill lagene før du endrer krypto

Tre spørsmål klassifiserer feilen. Valgte kjernen en rute som avviser målet? Valgte den en gyldig rute, men klarte ikke å slå opp neste hopp? Eller ankom en rapport fra utenfor det lokale nettverket? Bare det tredje tilfellet kan involvere tunnelens fjerne ende, og selv da ikke krypteringen.

Problemer med autentisering og forhandling viser seg som egne feil etter at transporten når peeren. Å endre en chiffer eller reinstallere klienten kan ikke rette en lokal unreachable-rute, og det ødelegger rute- og nabobeviset du ville trengt for den virkelige årsaken.

Registrer mål, navnerom, valgt tabell, neste hopp, nabostatus og feiltidspunkt før den første endringen. Kjør det samme oppslaget på nytt etter rettelsen; en rute som nå peker på tunnelen, og en nabooppføring som nå slås opp, er sterkere bevis enn en vellykket ping til en uvedkommende adresse.