Linux EHOSTUNREACH OpenVPN-nel: melyik következő ugrás hibázott?

Az EHOSTUNREACH ugyanolyan gyakran helyi döntés, mint távoli hiba. A kernel elutasíthat egy csomagot, mert egy útvonal azt mondja, hogy a cél elérhetetlen, mert az Ethernet következő ugrás soha nem válaszolt, vagy mert egy ICMP host-unreachable jelentés érkezett messzebbről az útvonalon. Minden forrás más táblában vagy gyorsítótárban él, és mindegyiket más helyen javítják. Olvassa el a kiválasztott útvonalat és a következő ugrás állapotát, mielőtt a titkosításhoz nyúl vagy újratelepíti az alagutat.

Válassza ki azt a címet és névteret, amelyet az ügyfél valóban használ

Kezdje a hibát okozó cél és hálózati névtér rögzítésével. Egy VPN-ügyfél a saját névterében futhat, és az alapértelmezett névtérből végzett keresés egy másik útválasztási táblát kérdez le, más házirend-szabályokkal.

A keresésnek ugyanazt a forrás-, jelölés- és táblakontextust kell használnia, mint a hibázó alkalmazásnak, különben olyan kérdésre válaszolhat, amelyet senki sem tett fel. Egy szemléltető IPv4-társ esetében a csak olvasási ellenőrzések ezek:

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

Egy rendszergazdai héjból származó eredmény csak azt bizonyítja, hogy az a héj mit tenne. Ha az ügyfél tűzfal-jelölést állít be, vagy VRF-hez kötődik, ismételje meg a keresést a megfelelő jelöléssel vagy a VRF-en belül, és hasonlítsa össze a kiválasztott útvonalat és a következő ugrást. Az első megerősítendő cím a profilban lévő társ címe, nem a felhasználó által megnevezett klaszter vagy szolgáltatás.

Egy kifejezett elérhetetlen útvonal helyben elutasítja a csomagot

Az unreachable típusú útvonal szándékos helyi válasz. Azt mondja a kernelnek, hogy dobja el a csomagot, és küldje vissza az EHOSTUNREACH-et a feladónak, ezért a hiba azonnal, a gépet elhagyó forgalom nélkül jelenik meg. Valaki vagy valamilyen automatizálás szándékosan tette oda azt az útvonalat.

Az útvonaltípusok nem cserélhetők fel. A blackhole hiba nélkül dobja el a csomagot a feladónak, a prohibit EACCES-t ad vissza, az unreachable pedig EHOSTUNREACH-et. Ezért egy VPN-segéd, amely újracsatlakozáskor nyelő útvonalat telepít, host-unreachable hibák rohamát okozhatja, amelyek eltűnnek, amint az alagút feláll, míg egy blackhole útvonal inkább csendes időtúllépéseket okozna.

Keresse meg a típust minden táblában, mielőtt a távoli véget okolná. A táblát kiválasztó szabály ugyanolyan fontos, mint a benne lévő útvonal, és a főtáblához adott útvonal nem segít egy olyan ügyfélen, amelynek házirend-szabálya máshová küldi a forgalmát.

Egy halott szomszéd ugyanezt a hibát okozza Etherneten

Amikor a kiválasztott útvonal linken lévő átjárót használ, a kézbesítéshez feloldott kapcsolati rétegű cím kell. A kernel ARP- vagy IPv6-szomszédkérést küld, és ha nem érkezik válasz, a csomag nem keretezhető. A küldés ekkor EHOSTUNREACH-csel hibázik, pedig maga az útvonal érvényes.

A szomszédtábla nevezi meg a fázist. Az INCOMPLETE azt jelenti, hogy a feloldás még folyamatban van, a FAILED azt, hogy az utolsó kísérlet nem kapott választ, a REACHABLE vagy STALE pedig azt, hogy a kernelnek használható címe van. A VPN-átjáró FAILED bejegyzése helyi kézbesítési probléma, nem bizonyíték az alagút túlsó oldaláról.

A bejegyzést a tényleges következő ugráshoz olvassa, ne a távoli internetcímhez. Egy távoli címet általában routeren keresztül érünk el, ezért nem lesz saját ARP-rekordja; ilyet kérni kategóriahiba, amely embereket egy soha nem létezni hivatott hiányzó bejegyzés keresésére küld.

Távoli jelentések és aszinkron UDP-hibák

Az EHOSTUNREACH kívülről is érkezhet. Egy router, amely nem tudja továbbítani a csomagot, ICMP host unreachable-t küldhet, és a kernel ezt a jelentést átadja a folyamatot birtokló socketnek. Ebben az esetben az útvonal és a szomszéd rendben van, és a hiba a helyi hálózaton túli ugráshoz tartozik.

Az UDP megnehezíti az azonosítást. Egy későbbi send vagy receive hívás által visszaadott hiba egy korábbi datagramra utalhat, ezért a hibázó hívás címe és ideje nem feltétlenül egyezik azzal a csomaggal, amely a jelentést kiváltotta. Egy csatlakoztatott UDP-socket egyszer kapja meg a hibát, egy nem csatlakoztatott socket pedig lehet, hogy soha nem látja.

Ezért az időzítés a bizonyíték része. Jegyezze fel, mikor jelent meg a hiba, melyik társ címet használta a socket, és hogy az alagút éppen újracsatlakozott-e. Egy roham közvetlenül egy útvonalváltozás után a helyi táblára mutat; egyetlen hiba egy stabil folyamat percei után egy útvonaljelentésre.

Válassza szét a rétegeket, mielőtt a kriptót módosítja

Három kérdés osztályozza a hibát. A kernel olyan útvonalat választott, amely elutasítja a célt? Érvényes útvonalat választott, de nem tudta feloldani a következő ugrást? Vagy a helyi hálózaton túlról érkezett jelentés? Csak a harmadik eset érintheti az alagút távoli végét, és még akkor sem érinti a titkosítást.

A hitelesítési és egyeztetési problémák saját hibákként jelennek meg, miután a szállítás eléri a társat. Egy titkosítás cseréje vagy az ügyfél újratelepítése nem javít egy helyi unreachable útvonalat, és tönkreteszi azokat az útvonal- és szomszédbizonyítékokat, amelyekre a valódi okhoz szüksége lenne.

Az első változtatás előtt rögzítse a célt, a névteret, a kiválasztott táblát, a következő ugrást, a szomszéd állapotát és a hiba idejét. A javítás után futtassa újra ugyanazt a keresést; egy útvonal, amely most az alagútra mutat, és egy szomszédbejegyzés, amely most feloldódik, erősebb bizonyíték, mint egy sikeres ping egy nem kapcsolódó címre.