Linux EHOSTUNREACH OpenVPN-iga: milline järgmine hüpe ebaõnnestus?

EHOSTUNREACH on sama sageli kohalik otsus kui kaugviga. Kernel võib paketi tagasi lükata, sest marsruut ütleb, et sihtkoht on kättesaamatu, sest Etherneti järgmine hüpe ei vastanud kunagi, või sest tee kaugemalt saabus ICMP host-unreachable aruanne. Iga allikas elab eri tabelis või vahemälus ja igaüht parandatakse eri kohas. Lugege valitud marsruuti ja järgmise hüppe olekut enne, kui puudutate šifreid või paigaldate tunnelit uuesti.

Valige aadress ja nimeruum, mida klient tegelikult kasutab

Alustage sihtkoha ja selle võrgu nimeruumi kinnitamisest, mis vea tekitas. VPN-klient võib töötada oma nimeruumis ja vaikenimeruumist tehtud otsing konsulteerib teise marsruutimistabeliga, millel on teised poliitikareeglid.

Otsing peab kasutama sama allika-, märke- ja tabelikonteksti kui ebaõnnestuv rakendus, muidu võib see vastata küsimusele, mida keegi ei küsinud. Illustratiivse IPv4 partneri puhul on ainult lugemiseks mõeldud kontrollid järgmised:

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

Administratiivsest kestast saadud tulemus tõestab ainult seda, mida see kest teeks. Kui klient määrab tulemüüri märke või seob end VRF-iga, korrake otsingut vastava märgiga või VRF-i sees ning võrrelge valitud marsruuti ja järgmist hüpet. Esimene kinnitatav aadress on profiilis olev partneri aadress, mitte klastri või teenuse nimi, mille kasutaja nimetab.

Selgesõnaline kättesaamatu marsruut lükkab paketi kohapeal tagasi

Tüübi unreachable marsruut on tahtlik kohalik vastus. See ütleb kernelile pakett ära visata ja saata EHOSTUNREACH saatjale tagasi, mistõttu viga ilmub kohe ja ilma ühegi liikluseta, mis masinast lahkub. Keegi või mingi automatiseerimine pani selle marsruudi sinna meelega.

Marsruuditüübid ei ole vahetatavad. Blackhole viskab paketi ära ilma saatjale veateateta, prohibit tagastab EACCES ja unreachable tagastab EHOSTUNREACH. Seetõttu võib VPN-abivahend, mis paigaldab taasühenduse ajal neelava marsruudi, tekitada host-unreachable vigade purske, mis kaob, kui tunnel püsti saab, samas kui blackhole-marsruut tekitaks hoopis vaikseid aegumisi.

Otsige tüüpi kõigist tabelitest enne, kui süüdistate kaugpoolt. Tabeli valiv reegel loeb sama palju kui marsruut selle sees, ja põhitabelisse lisatud marsruut ei aita klienti, kelle poliitikareegel saadab selle liikluse mujale.

Surnud naaber tekitab Ethernetis sama vea

Kui valitud marsruut kasutab lingil olevat lüüsi, vajab kohaletoimetamine lahendatud lingikihi aadressi. Kernel saadab ARP- või IPv6-naabripäringu ja kui vastust ei tule, ei saa paketti raamida. Siis ebaõnnestub saatmine EHOSTUNREACH-iga, kuigi marsruut ise on kehtiv.

Naabritabel nimetab etapi. INCOMPLETE tähendab, et lahendus on veel käimas, FAILED tähendab, et viimane katse ei saanud vastust, ning REACHABLE või STALE tähendab, et kernelil on kasutatav aadress. VPN-lüüsi FAILED-kirje on kohalik kohaletoimetamise probleem, mitte tõend tunneli kaugema poole kohta.

Lugege kirjet tegeliku järgmise hüppe kohta, mitte kaugema internetiaadressi kohta. Kaugemale aadressile jõutakse tavaliselt ruuteri kaudu, seega ei ole sellel oma ARP-kirjet; selle küsimine on kategooriaviga, mis saadab inimesi otsima puuduvat kirjet, mida ei olekski pidanud olema.

Kauged aruanded ja asünkroonsed UDP-vead

EHOSTUNREACH võib tulla ka väljastpoolt. Ruuter, mis ei saa paketti edasi saata, võib saata ICMP host unreachable ja kernel edastab selle aruande socketile, mis voogu omab. Sel juhul on marsruut ja naaber korras ning tõrge kuulub kohalikust võrgust kaugemale hüppele.

UDP teeb omistamise raskemaks. Hilisema saatmis- või vastuvõtukutse tagastatud viga võib viidata varasemale datagrammile, seega ei pruugi ebaõnnestuva kutse aadress ja aeg kattuda paketiga, mis aruande käivitas. Ühendatud UDP-socket saab vea üks kord ja ühendamata socket ei pruugi seda kunagi näha.

Seetõttu kuulub aeg tõendite hulka. Märkige üles, millal viga ilmus, millist partneri aadressi socket kasutas ja kas tunnel oli just uuesti ühendunud. Pursk vahetult pärast marsruudimuutust osutab kohalikule tabelile; üksik viga mitu minutit pärast stabiilse voolu algust osutab teearuandele.

Eraldage kihid enne krüpto muutmist

Kolm küsimust liigitavad vea. Kas kernel valis marsruudi, mis lükkab sihtkoha tagasi? Kas ta valis kehtiva marsruudi, kuid ei suutnud järgmist hüpet lahendada? Või saabus aruanne kohalikust võrgust kaugemalt? Ainult kolmas juhtum võib hõlmata tunneli kaugemat otsa ja isegi siis mitte krüpteerimist.

Autentimis- ja läbirääkimisprobleemid ilmuvad omaette vigadena pärast seda, kui transport jõuab partnerini. Šifri muutmine või kliendi uuesti paigaldamine ei saa parandada kohalikku unreachable-marsruuti ja hävitab marsruudi- ja naabritõendid, mida tegeliku põhjuse jaoks vajaksite.

Enne esimest muudatust registreerige sihtkoht, nimeruum, valitud tabel, järgmine hüpe, naabri olek ja vea aeg. Pärast parandust käivitage sama otsing uuesti; marsruut, mis nüüd osutab tunnelile, ja naabrikirje, mis nüüd lahendub, on tugevam tõend kui edukas ping seotud aadressile.