Linux EHOSTUNREACH med OpenVPN: kva neste hopp mislukkast?

EHOSTUNREACH er like ofte eit lokalt vedtak som ein fjern feil. Kjernen kan avvise ein pakke fordi ei rute seier at målet er utilgjengeleg, fordi Ethernet-nestehoppet aldri svara, eller fordi ein ICMP host-unreachable-rapport kom lenger framme på stien. Kvar kjelde lever i ein annan tabell eller hurtigbuffer, og kvar einskild blir retta på ein annan stad. Les den valde ruta og tilstanden til neste hopp før du rører chiffrar eller reinstallerer tunnelen.

Vel adressa og namnerommet klienten faktisk brukar

Byrja med å feste målet og nettverksnamnerommet som skapte feilen. Ein VPN-klient kan køyre i sitt eige namnerom, og eit oppslag frå standardnamnerommet konsulterer ein annan rutetabell med andre policyreglar.

Oppslaget må bruke same kjelde-, mark- og tabellkontekst som programmet som feilar, elles kan det svare på eit spørsmål ingen stilte. For ein illustrativ IPv4-peer er skriveverna kontrollar:

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

Eit resultat frå ein administrativ shell beviser berre kva den shellen ville gjere. Viss klienten set eit brannmurmark eller bind til ein VRF, gjer oppslaget på nytt med samsvarande mark eller inne i VRF-en, og samanlikn den valde ruta og neste hopp. Den første adressa som skal stadfestast, er peer-adressa i profilen, ikkje klynga eller tenesta brukaren nemner.

Ei eksplisitt utilgjengeleg rute avviser pakken lokalt

Ei rute av typen unreachable er eit medvite lokalt svar. Ho ber kjernen kaste pakken og returnere EHOSTUNREACH til avsendaren, og difor viser feilen seg med ein gong og utan trafikk som forlèt maskinen. Nokon, eller ein automatisering, sette den ruta der med vilje.

Rutetypane kan ikkje bytast om. Blackhole kastar pakken utan feil til avsendaren, prohibit returnerer EACCES, og unreachable returnerer EHOSTUNREACH. Ein VPN-hjelpar som installerer ei slukrute under attilkopling, kan difor gje ei byge av host-unreachable-feil som forsvinn når tunnelen er oppe, medan ei blackhole-rute i staden ville gje stille tidsavbrot.

Søk gjennom alle tabellar etter typen før du klandrar den fjerne enden. Regelen som vel tabellen, tyder like mykje som ruta i han, og ei rute lagd til hovudtabellen hjelper ikkje ein klient der policyregelen sender trafikken hans ein annan stad.

Ein død nabo gjev same feil på Ethernet

Når den valde ruta brukar ein on-link-gateway, treng leveringa ei oppslått lenkjelagsadresse. Kjernen sender ein ARP- eller IPv6-naboførespurnad, og viss det ikkje kjem svar, kan pakken ikkje rammast inn. Sendinga feilar då med EHOSTUNREACH sjølv om ruta sjølv er gyldig.

Nabotabellen namngjev fasen. INCOMPLETE tyder at ei oppslåing pågår, FAILED tyder at siste forsøk ikkje fekk svar, og REACHABLE eller STALE tyder at kjernen har ei brukbar adresse. Ei FAILED-oppføring for VPN-gatewayen er eit lokalt leveringsproblem, ikkje bevis om den fjerne sida av tunnelen.

Les oppføringa for det faktiske neste hoppet, ikkje for den fjerne internettadressa. Ei fjern adresse blir vanlegvis nådd via ein ruter, så ho vil ikkje ha si eiga ARP-oppføring; å spørje etter ei er ein kategorifeil som sender folk på jakt etter ei manglande oppføring som aldri skulle ha eksistert.

Fjerne rapportar og asynkrone UDP-feil

EHOSTUNREACH kan òg kome utanfrå. Ein ruter som ikkje kan videresende pakken, kan sende ICMP host unreachable, og kjernen gjev den rapporten vidare til sockelen som eig flyten. I så fall er ruta og naboen i orden, og feilen høyrer til eit hopp utanfor det lokale nettverket.

UDP gjer tilskrivinga vanskelegare. Ein feil som blir returnert av eit seinare send- eller receive-kall, kan gjelde eit tidlegare datagram, så adressa og tidspunktet for det feilande kallet passar kanskje ikkje til pakken som utløyste rapporten. Ein tilkopla UDP-sockel mottek feilen éin gong, og ein utilkopla sockel ser han kanskje aldri.

Difor høyrer timing med i beviset. Noter når feilen dukka opp, kva peer-adresse sockelen brukte, og om tunnelen nettopp var attilkopla. Ei byge rett etter ei ruteendring peikar på den lokale tabellen; ein einsleg feil minutt inn i ein stabil flyt peikar på ein stirapport.

Skil laga før du endrar krypto

Tre spørsmål klassifiserer feilen. Valde kjernen ei rute som avviser målet? Valde han ei gyldig rute, men klarte ikkje å slå opp neste hopp? Eller kom ein rapport frå utanfor det lokale nettverket? Berre det tredje tilfellet kan involvere den fjerne enden av tunnelen, og sjølv då ikkje krypteringa.

Problem med autentisering og forhandling viser seg som eigne feil etter at transporten når peeren. Å endre ein chiffer eller reinstallere klienten kan ikkje rette ei lokal unreachable-rute, og det øydelegg rute- og nabobeviset du ville trenge for den verkelege årsaka.

Registrer mål, namnerom, vald tabell, neste hopp, nabostatus og feiltidspunkt før den første endringa. Køyr det same oppslaget på nytt etter rettinga; ei rute som no peikar på tunnelen, og ei nabooppføring som no blir slått opp, er sterkare bevis enn ein vellukka ping til ei uvedkommande adresse.