Linux EHOSTUNREACH me OpenVPN: cila hop tjetër dështoi?

EHOSTUNREACH është po aq shpesh një vendim lokal sa një dështim i largët. Kerneli mund të refuzojë një paketë sepse një rrugë thotë se destinacioni është unreachable, sepse hop-i tjetër Ethernet nuk u përgjigj kurrë, ose sepse një raport ICMP host-unreachable mbërriti nga më tej në rrugë. Çdo burim jeton në një tabelë ose cache tjetër dhe secili rregullohet në një vend tjetër. Lexoni rrugën e zgjedhur dhe gjendjen e hop-it tjetër përpara se të prekni shifrat ose të riinstaloni tunelin.

Zgjidhni adresën dhe namespace-in që klienti përdor në të vërtetë

Filloni duke fiksuar destinacionin dhe namespace-in e rrjetit që prodhoi gabimin. Një klient VPN mund të ekzekutohet në namespace-in e vet, dhe një kërkim nga ai i parazgjedhur konsulton një tabelë tjetër rrugëtimi me rregulla të tjera politike.

Kërkimi duhet të përdorë të njëjtin burim, mark dhe kontekst tabele si aplikacioni që dështon, përndryshe mund t'i përgjigjet një pyetjeje që askush nuk e bëri. Për një peer ilustrues IPv4, kontrollet vetëm-lexim janë:

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

Një rezultat nga një shell administrativ vërteton vetëm atë që do të bënte ai shell. Nëse klienti vendos një firewall mark ose lidhet me një VRF, përsëritni kërkimin me mark-un përkatës ose brenda VRF-së dhe krahasoni rrugën e zgjedhur dhe hop-in tjetër. Adresa e parë për t'u konfirmuar është adresa peer në profil, jo grupi ose shërbimi që emërton përdoruesi.

Një rrugë unreachable e qartë e refuzon paketën lokalisht

Një rrugë e tipit unreachable është një përgjigje lokale e qëllimshme. Ajo i thotë kernelit ta hedhë paketën dhe t'i kthejë dërguesit EHOSTUNREACH, prandaj gabimi shfaqet menjëherë dhe pa asnjë trafik që lë makinën. Dikush, ose ndonjë automatizim, e vendosi atë rrugë atje me qëllim.

Tipet e rrugëve nuk janë të këmbyeshme. blackhole e hedh paketën pa gabim për dërguesin, prohibit kthen EACCES dhe unreachable kthen EHOSTUNREACH. Një ndihmës VPN që instalon një rrugë sink gjatë rilidhjes mund të prodhojë kështu një shpërthim gabimesh host-unreachable që zhduken pasi tuneli ngrihet, ndërsa një rrugë blackhole do të prodhonte në vend të tyre skadime të heshtura.

Kërkoni tipin në të gjitha tabelat përpara se të fajësoni skajin e largët. Rregulli që zgjedh tabelën ka po aq rëndësi sa rruga brenda saj, dhe një rrugë e shtuar në tabelën kryesore nuk do të ndihmojë një klient, rregulli politik i të cilit e dërgon trafikun diku tjetër.

Një fqinj i vdekur prodhon të njëjtin gabim në Ethernet

Kur rruga e zgjedhur përdor një gateway on-link, dorëzimi kërkon një adresë të zgjidhur të shtresës së lidhjes. Kerneli dërgon një ARP ose një kërkesë fqinji IPv6, dhe nëse nuk mbërrin përgjigje, paketa nuk mund të kornizohet. Dërgimi pastaj dështon me EHOSTUNREACH edhe pse vetë rruga është e vlefshme.

Tabela e fqinjëve emërton fazën. INCOMPLETE do të thotë që një zgjidhje është ende në vazhdim, FAILED do të thotë që përpjekja e fundit nuk mori përgjigje, dhe REACHABLE ose STALE do të thotë që kerneli ka një adresë të përdorshme. Një zë FAILED për gateway-in VPN është problem dorëzimi lokal, jo provë për anën e largët të tunelit.

Lexoni zërin për hop-in tjetër aktual, jo për adresën e largët të internetit. Një adresë e largët normalisht arrihet përmes një router, prandaj nuk do të ketë një regjistrim ARP të vetin; kërkimi i një të tilli është gabim kategorie që i dërgon njerëzit të kërkojnë një zë që mungon dhe që nuk duhej të ekzistonte kurrë.

Raportet e largëta dhe gabimet asinkrone UDP

EHOSTUNREACH mund të mbërrijë edhe nga jashtë. Një router që nuk mund ta përcjellë paketën mund të dërgojë ICMP host unreachable, dhe kerneli ia kalon atë raport socket-it që zotëron rrjedhën. Në atë rast rruga dhe fqinji janë në rregull, dhe dështimi i përket një hop-i përtej rrjetit lokal.

UDP e vështirëson atribuimin. Një gabim i kthyer nga një thirrje send ose receive e mëvonshme mund t'i referohet një datagrami të mëparshëm, prandaj adresa dhe koha e thirrjes që dështon mund të mos përputhen me paketën që shkaktoi raportin. Një socket UDP i lidhur e merr gabimin një herë, dhe një socket i palidhur mund të mos e shohë kurrë.

Kjo është arsyeja pse koha i përket provave. Shënoni kur u shfaq gabimi, cilën adresë peer përdori socket-i dhe nëse tuneli sapo ishte rilidhur. Një shpërthim menjëherë pas një ndryshimi rruge tregon tabelën lokale; një gabim i vetëm minuta pas një rrjedhe të qëndrueshme tregon një raport rruge.

Ndani shtresat përpara se të ndryshoni kriptografinë

Tre pyetje e klasifikojnë gabimin. A zgjodhi kerneli një rrugë që e refuzon destinacionin? A zgjodhi një rrugë të vlefshme por dështoi të zgjidhë hop-in tjetër? Apo mbërriti një raport nga përtej rrjetit lokal? Vetëm rasti i tretë mund të implikojë skajin e largët të tunelit, dhe edhe atëherë nuk implikon kriptimin.

Problemet e autentikimit dhe negociimit shfaqen si gabime të tyre pasi transporti arrin peer-in. Ndryshimi i një shifre ose riinstalimi i klientit nuk mund të rregullojë një rrugë unreachable lokale, dhe shkatërron provat e rrugës dhe të fqinjit që do t'ju duheshin për shkakun e vërtetë.

Regjistroni destinacionin, namespace-in, tabelën e zgjedhur, hop-in tjetër, gjendjen e fqinjit dhe kohën e gabimit përpara ndryshimit të parë. Rifreskoni të njëjtin kërkim pas rregullimit; një rrugë që tani tregon tunelin dhe një zë fqinji që tani zgjidhet janë provë më e fortë sesa një ping i suksesshëm drejt një adrese të palidhur.