Linux EHOSTUNREACH su OpenVPN: kuris kitas šuolis nepavyko?

EHOSTUNREACH yra vietinis sprendimas taip pat dažnai, kaip ir tolimas gedimas. Branduolys gali atmesti paketą, nes maršrutas sako, kad paskirties vieta nepasiekiama, nes Ethernet kitas šuolis niekada neatsakė, arba nes ICMP host-unreachable ataskaita atėjo iš toliau kelyje. Kiekvienas šaltinis gyvena skirtingoje lentelėje ar talpykloje, ir kiekvienas taisomas skirtingoje vietoje. Perskaitykite pasirinktą maršrutą ir kito šuolio būseną prieš liesdami šifrus ar perinstaliuodami tunelį.

Pasirinkite adresą ir vardų erdvę, kuriuos klientas iš tikrųjų naudoja

Pradėkite užfiksuodami paskirties vietą ir tinklo vardų erdvę, kuri sukėlė klaidą. VPN klientas gali veikti savo vardų erdvėje, o paieška iš numatytosios vardų erdvės konsultuoja kitą maršrutizavimo lentelę su kitomis politikos taisyklėmis.

Paieška turi naudoti tą patį šaltinio, žymės ir lentelės kontekstą kaip ir nepavykstanti programa, kitaip ji gali atsakyti į klausimą, kurio niekas neuždavė. Iliustraciniam IPv4 partneriui tik skaitymo patikros yra šios:

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

Rezultatas iš administracinio apvalkalo įrodo tik tai, ką tas apvalkalas darytų. Jei klientas nustato ugniasienės žymę arba susieja su VRF, pakartokite paiešką su atitinkama žyme arba VRF viduje ir palyginkite pasirinktą maršrutą bei kitą šuolį. Pirmasis patvirtinamas adresas yra profilio partnerio adresas, o ne klasteris ar paslauga, kurią nurodo naudotojas.

Aiškus nepasiekiamas maršrutas atmeta paketą vietoje

unreachable tipo maršrutas yra tyčinis vietinis atsakymas. Jis liepia branduoliui išmesti paketą ir grąžinti EHOSTUNREACH siuntėjui, todėl klaida atsiranda akimirksniu ir be jokio srauto, paliekančio mašiną. Kažkas arba kokia nors automatizacija tyčia įdėjo tą maršrutą ten.

Maršrutų tipai nėra keičiami. Blackhole išmeta paketą be klaidos siuntėjui, prohibit grąžina EACCES, o unreachable grąžina EHOSTUNREACH. Todėl VPN pagalbininkas, kuris perjungimo metu įdiegia nuotėkio maršrutą, gali sukelti host-unreachable klaidų pliūpsnį, kuris dingsta, kai tunelis pakyla, o blackhole maršrutas vietoj to sukeltų tylius laukimo terminus.

Ieškokite tipo visose lentelėse prieš kaltindami tolimą galą. Taisyklė, kuri parenka lentelę, svarbi tiek pat, kiek maršrutas joje, o maršrutas, pridėtas prie pagrindinės lentelės, nepadės klientui, kurio politikos taisyklė siunčia jo srautą kitur.

Negyvas kaimynas sukelia tą pačią klaidą Ethernet tinkle

Kai pasirinktas maršrutas naudoja saite esančius vartus, pristatymui reikia išspręsto saito lygmens adreso. Branduolys siunčia ARP arba IPv6 kaimyno užklausą, o jei atsakymo nėra, paketas negali būti įrėmintas. Tada siuntimas nepavyksta su EHOSTUNREACH, nors pats maršrutas galioja.

Kaimynų lentelė įvardija etapą. INCOMPLETE reiškia, kad sprendimas dar vyksta, FAILED reiškia, kad paskutinis bandymas negavo atsakymo, o REACHABLE arba STALE reiškia, kad branduolys turi tinkamą adresą. VPN vartų FAILED įrašas yra vietinė pristatymo problema, o ne įrodymas apie tolimą tunelio pusę.

Skaitykite įrašą apie tikrąjį kitą šuolį, o ne apie tolimą interneto adresą. Tolimas adresas paprastai pasiekiamas per maršrutizatorių, todėl neturės savo ARP įrašo; jo prašyti yra kategorijos klaida, leidžianti žmonėms ieškoti trūkstamo įrašo, kurio niekada neturėjo būti.

Tolimos ataskaitos ir asinchroninės UDP klaidos

EHOSTUNREACH gali atkeliauti ir iš išorės. Maršrutizatorius, kuris negali persiųsti paketo, gali siųsti ICMP host unreachable, o branduolys perduoda tą ataskaitą lizdui, kuriam priklauso srautas. Tokiu atveju maršrutas ir kaimynas yra tvarkingi, o gedimas priklauso šuoliui už vietinio tinklo.

UDP apsunkina priskyrimą. Klaida, kurią grąžina vėlesnis siuntimo arba priėmimo kvietimas, gali būti susijusi su ankstesne datagrama, todėl nepavykstančio kvietimo adresas ir laikas gali nesutapti su paketu, kuris sukėlė ataskaitą. Prisijungęs UDP lizdas klaidą gauna vieną kartą, o neprisijungęs lizdas gali jos niekada nepamatyti.

Todėl laikas priklauso įrodymams. Užsirašykite, kada klaida atsirado, kurį partnerio adresą naudojo lizdas ir ar tunelis ką tik buvo prijungtas iš naujo. Pliūpsnis iškart po maršruto pakeitimo nurodo į vietinę lentelę; viena klaida po kelių minučių stabilaus srauto nurodo į kelio ataskaitą.

Atskirkite sluoksnius prieš keisdami kriptografiją

Trys klausimai klasifikuoja klaidą. Ar branduolys pasirinko maršrutą, kuris atmeta paskirties vietą? Ar jis pasirinko galiojantį maršrutą, bet nesugebėjo išspręsti kito šuolio? O gal ataskaita atkeliavo iš už vietinio tinklo? Tik trečiasis atvejis gali paveikti tolimą tunelio galą, ir net tada jis nepaveikia šifravimo.

Autentifikavimo ir derybų problemos pasirodo kaip savo klaidos po to, kai transportas pasiekia partnerį. Šifro pakeitimas arba kliento perinstaliavimas negali pataisyti vietinio unreachable maršruto, ir jis sunaikina maršruto bei kaimyno įrodymus, kurių prireiktų tikrajai priežasčiai.

Prieš pirmąjį pakeitimą užrašykite paskirties vietą, vardų erdvę, pasirinktą lentelę, kitą šuolį, kaimyno būseną ir klaidos laiką. Po pataisymo paleiskite tą pačią paiešką dar kartą; maršrutas, kuris dabar rodo į tunelį, ir kaimyno įrašas, kuris dabar išsprendžiamas, yra stipresnis įrodymas nei sėkmingas ping į nesusijusį adresą.