Linux EHOSTUNREACH kun OpenVPN: kiu sekva salto malsukcesis?

EHOSTUNREACH estas loka decido same ofte kiel fora fiasko. La kerno povas malakcepti paketon ĉar itinero diras ke la celo estas neatingebla, ĉar la sekva Ethernet-salto neniam respondis, aŭ ĉar ICMP host-unreachable-raporto alvenis de pli malproksime laŭ la vojo. Ĉiu fonto vivas en malsama tabelo aŭ kaŝmemoro, kaj ĉiu estas riparata en malsama loko. Legu la elektitan itineron kaj la staton de la sekva salto antaŭ ol tuŝi ĉifrojn aŭ reinstali la tunelon.

Elektu la adreson kaj nomspacon kiujn la kliento efektive uzas

Komencu fiksante la celon kaj la retan nomspacon kiu produktis la eraron. VPN-kliento povas ruli en sia propra nomspaco, kaj serĉo el la implicita nomspaco konsultas alian enkursig-tabelon kun aliaj politikaj reguloj.

La serĉo devas uzi la saman font-, mark- kaj tabelkuntekston kiel la fiaskanta aplikaĵo, alie ĝi eble respondos demandon kiun neniu faris. Por ilustra IPv4-kunulo, la nurlegaj kontroloj estas:

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

Rezulto el administra ŝelo pruvas nur kion tiu ŝelo farus. Se la kliento agordas fajroŝirmilan markon aŭ ligiĝas al VRF, ripetu la serĉon kun la kongrua marko aŭ ene de la VRF, kaj komparu la elektitan itineron kaj la sekvan salon. La unua adreso konfirmenda estas la kunula adreso en la profilo, ne la klistero aŭ servo kiun la uzanto nomas.

Eksplicita neatingebla itinero malakceptas la paketon loke

Itinero de tipo unreachable estas intenca loka respondo. Ĝi diras al la kerno forĵeti la paketon kaj redoni EHOSTUNREACH al la sendinto, tial la eraro aperas tuj kaj sen iu ajn trafiko forlasanta la maŝinon. Iu, aŭ iu aŭtomatigo, metis tiun itineron tie intence.

La itineraj tipoj ne estas interŝanĝeblaj. Blackhole forĵetas la paketon sen eraro al la sendinto, prohibit redonas EACCES, kaj unreachable redonas EHOSTUNREACH. VPN-helpaĵo kiu instalas absorban itineron dum rekonekto povas do produkti eksplodon de host-unreachable-eraroj kiuj malaperas post kiam la tunelo supreniras, dum blackhole-itinero anstataŭe produktus silentajn tempolimojn.

Traserĉu ĉiujn tabelojn por la tipo antaŭ ol kulpigi la foran finon. La regulo kiu elektas la tabelon gravas same kiel la itinero ene de ĝi, kaj itinero aldonita al la ĉefa tabelo ne helpos klienton kies politika regulo sendas ĝian trafikon aliloken.

Mortinta najbaro produktas la saman eraron sur Ethernet

Kiam la elektita itinero uzas enligan pordegon, livero bezonas solvitan ligtavolan adreson. La kerno sendas ARP- aŭ IPv6-najbarpeton, kaj se neniu respondo alvenas la paketo ne povas esti enkadrigita. La sendo tiam fiaskas per EHOSTUNREACH eĉ kvankam la itinero mem estas valida.

La najbartabelo nomas la etapon. INCOMPLETE signifas ke solvo ankoraŭ progresas, FAILED signifas ke la lasta provo ne ricevis respondon, kaj REACHABLE aŭ STALE signifas ke la kerno havas uzeblan adreson. FAILED-enskribo por la VPN-pordego estas loka liverproblemo, ne pruvo pri la fora flanko de la tunelo.

Legu la enskribon por la fakta sekva salto, ne por la fora interreta adreso. Fora adreso kutime atingiĝas per enkursigilo, do ĝi ne havos propran ARP-rikordon; peti unu estas kategoria eraro kiu sendas homojn serĉi mankantan enskribon kiu neniam devis ekzisti.

Foraj raportoj kaj nesinkronaj UDP-eraroj

EHOSTUNREACH povas ankaŭ alveni de ekstere. Enkursigilo kiu ne povas plusendi la paketon eble sendas ICMP host unreachable, kaj la kerno transdonas tiun raporton al la ingo kiu posedas la fluon. En tiu kazo la itinero kaj najbaro estas en ordo, kaj la fiasko apartenas al salto preter la loka reto.

UDP malfaciligas la atribuon. Eraro redonita de posta send- aŭ ricev-voko povas rilati al pli frua datagramo, do la adreso kaj tempo de la fiaskanta voko eble ne kongruas kun la paketo kiu ekigis la raporton. Konektita UDP-ingo ricevas la eraron unufoje, kaj nekonektita ingo eble neniam vidos ĝin.

Tial tempo apartenas al la pruvoj. Notu kiam la eraro aperis, kiun kunulan adreson la ingo uzis, kaj ĉu la tunelo ĵus rekonektiĝis. Eksplodo tuj post itinera ŝanĝo montras al la loka tabelo; unuopa eraro minutojn en stabila fluo montras al voja raporto.

Apartigu la tavolojn antaŭ ol ŝanĝi kripton

Tri demandoj klasifikas la eraron. Ĉu la kerno elektis itineron kiu malakceptas la celon? Ĉu ĝi elektis validan itineron sed malsukcesis solvi la sekvan salon? Aŭ ĉu raporto alvenis de preter la loka reto? Nur la tria kazo povas impliki la foran finon de la tunelo, kaj eĉ tiam ĝi ne implikas ĉifradon.

Aŭtentikigaj kaj intertraktaj problemoj aperas kiel propraj eraroj post kiam la transporto atingas la kunulon. Ŝanĝi ĉifron aŭ reinstali la klienton ne povas ripari lokan unreachable-itineron, kaj ĝi detruas la pruvojn pri itinero kaj najbaro kiujn vi bezonus por la reala kaŭzo.

Registru la celon, nomspacon, elektitan tabelon, sekvan salon, najbar-staton kaj erartempon antaŭ la unua ŝanĝo. Relanĉu la saman serĉon post la riparo; itinero kiu nun montras al la tunelo kaj najbar-enskribo kiu nun solviĝas estas pli forta pruvo ol sukcesa ping al nerilata adreso.