Linux in EHOSTUNREACH z OpenVPN: kateri naslednji skok je odpovedal?

EHOSTUNREACH je enako pogosto lokalna odločitev kot oddaljena odpoved. Jedro lahko paket zavrne, ker pot pravi, da je cilj nedosegljiv, ker ethernetni naslednji skok ni nikoli odgovoril, ali ker je po poti od dlje prišlo sporočilo ICMP host-unreachable. Vsak vir živi v drugi tabeli ali predpomnilniku in vsak se popravi na drugem mestu. Preberite izbrano pot in stanje naslednjega skoka, preden se dotaknete šifer ali znova namestite tunel.

Izberite naslov in imenski prostor, ki ju odjemalec dejansko uporablja

Začnite tako, da določite cilj in imenski prostor omrežja, ki je povzročil napako. Odjemalec VPN lahko teče v svojem imenskem prostoru, iskanje iz privzetega prostora pa uporabi drugo usmerjevalno tabelo z drugačnimi pravili politike.

Iskanje mora uporabiti isti vir, mark in kontekst tabele kot aplikacija, ki odpoveduje, sicer lahko odgovori na vprašanje, ki ga nihče ni postavil. Za ponazoritvenega sogovornika IPv4 so preverjanja samo za branje:

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

Rezultat iz skrbniške lupine dokazuje le, kaj bi ta lupina naredila. Če odjemalec nastavi požarni zid mark ali se veže na VRF, ponovite iskanje z ustreznim mark ali znotraj VRF in primerjajte izbrano pot in naslednji skok. Prvi naslov, ki ga je treba potrditi, je naslov sogovornika v profilu, ne gruča ali storitev, ki jo uporabnik navede.

Izrecna nedosegljiva pot zavrne paket lokalno

Pot vrste unreachable je nameren lokalni odgovor. Jedru naroči, naj paket zavrže in pošiljatelju vrne EHOSTUNREACH, zato se napaka pojavi takoj in brez kakršnega koli prometa, ki bi zapustil stroj. Nekdo ali neka avtomatizacija je to pot tja postavila namenoma.

Vrste poti niso zamenljive. blackhole paket zavrže brez napake za pošiljatelja, prohibit vrne EACCES in unreachable vrne EHOSTUNREACH. Pomočnik VPN, ki med ponovnim povezovanjem namesti ponorno pot, lahko zato ustvari izbruh napak host-unreachable, ki izginejo, ko je tunel vzpostavljen, medtem ko bi pot blackhole namesto tega povzročila tihe časovne omejitve.

Preden krivite oddaljeni konec, poiščite vrsto po vseh tabelah. Pravilo, ki izbere tabelo, je enako pomembno kot pot v njej, in pot, dodana v glavno tabelo, ne bo pomagala odjemalcu, katerega pravilo politike pošilja promet drugam.

Mrtev sosed ustvari enako napako na Ethernetu

Ko izbrana pot uporablja prehod na povezavi, dostava potrebuje razrešen naslov povezavne plasti. Jedro pošlje ARP ali sosedsko povpraševanje IPv6 in če ne prispe odgovor, paketa ni mogoče uokviriti. Pošiljanje nato odpove z EHOSTUNREACH, čeprav je pot sama veljavna.

Sosedska tabela poimenuje fazo. INCOMPLETE pomeni, da razreševanje še poteka, FAILED pomeni, da zadnji poskus ni dobil odgovora, REACHABLE ali STALE pa pomeni, da ima jedro uporaben naslov. Vnos FAILED za prehod VPN je lokalna težava dostave, ne dokaz o oddaljeni strani tunela.

Berite vnos za dejanski naslednji skok, ne za oddaljeni internetni naslov. Do oddaljenega naslova običajno pridemo prek usmerjevalnika, zato ne bo imel lastnega zapisa ARP; zahtevati ga je kategorijska napaka, ki pošilja ljudi iskat manjkajoči vnos, ki ne bi smel nikoli obstajati.

Oddaljena sporočila in asinhrone napake UDP

EHOSTUNREACH lahko pride tudi od zunaj. Usmerjevalnik, ki paketa ne more posredovati, lahko pošlje ICMP host unreachable, jedro pa to sporočilo preda vtičnici, ki ima tok. V tem primeru sta pot in sosed v redu, odpoved pa pripada skoku onkraj lokalnega omrežja.

UDP otežuje ugotavljanje vzroka. Napaka, ki jo vrne poznejši klic send ali receive, se lahko nanaša na prejšnji datagram, zato se naslov in čas klica, ki odpoveduje, morda ne ujemata s paketom, ki je sporočilo sprožil. Povezana vtičnica UDP prejme napako enkrat, nepovezana pa je morda sploh ne vidi.

Zato čas sodi v dokaze. Zabeležite, kdaj se je napaka pojavila, kateri naslov sogovornika je vtičnica uporabila in ali se je tunel pravkar znova povezal. Izbruh takoj po spremembi poti kaže na lokalno tabelo; posamezna napaka nekaj minut po stabilnem toku kaže na sporočilo s poti.

Pred spremembo kriptografije ločite plasti

Napako razvrstijo tri vprašanja. Je jedro izbralo pot, ki cilj zavrača? Je izbralo veljavno pot, a ni uspelo razrešiti naslednjega skoka? Ali je sporočilo prišlo od onkraj lokalnega omrežja? Samo tretji primer lahko vključi oddaljeni konec tunela in tudi takrat ne vključi šifriranja.

Težave z overjanjem in pogajanjem se pokažejo kot lastne napake, ko transport doseže sogovornika. Sprememba šifre ali ponovna namestitev odjemalca ne more popraviti lokalne nedosegljive poti in uniči dokaze o poti in sosedu, ki bi jih potrebovali za resnični vzrok.

Pred prvo spremembo zabeležite cilj, imenski prostor, izbrano tabelo, naslednji skok, stanje soseda in čas napake. Po popravku ponovite isto iskanje; pot, ki zdaj kaže na tunel, in sosedski vnos, ki se zdaj razreši, sta močnejši dokaz kot uspešen ping na nepovezan naslov.