Linux EHOSTUNREACH met OpenVPN: watter volgende hop het gefaal?

EHOSTUNREACH is net so dikwels 'n plaaslike besluit as 'n afgeleë fout. Die kern kan 'n pakket verwerp omdat 'n roete sê die bestemming is onbereikbaar, omdat die Ethernet-volgende hop nooit geantwoord het nie, of omdat 'n ICMP host-unreachable-verslag van verder langs die pad aangekom het. Elke bron woon in 'n ander tabel of kas, en elke een word op 'n ander plek reggemaak. Lees die gekose roete en die toestand van die volgende hop voordat jy syfers aanraak of die tonnel herinstalleer.

Kies die adres en naamruimte wat die kliënt werklik gebruik

Begin deur die bestemming en die netwerk-naamruimte vas te pen waarin die fout ontstaan het. 'n VPN-kliënt kan in sy eie naamruimte loop, en 'n opsoek vanaf die verstek-naamruimte raadpleeg 'n ander roetetabel met ander beleidsreëls.

Die opsoek moet dieselfde bron-, merkie- en tabelkonteks as die mislukkende toepassing gebruik, anders beantwoord dit dalk 'n vraag wat niemand gevra het nie. Vir 'n illustratiewe IPv4-eweknie is die lees-alleen kontroles:

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

'n Resultaat uit 'n administratiewe dop bewys net wat daardie dop sou doen. As die kliënt 'n vuurmuurmerkie stel of aan 'n VRF bind, herhaal die opsoek met die ooreenstemmende merkie of binne die VRF, en vergelyk die gekose roete en volgende hop. Die eerste adres om te bevestig is die eweknie-adres in die profiel, nie die groep of diens wat die gebruiker noem nie.

'n Eksplisiete onbereikbare roete verwerp die pakket plaaslik

'n Roete van die tipe unreachable is 'n doelbewuste plaaslike antwoord. Dit sê vir die kern om die pakket te gooi en EHOSTUNREACH aan die sender terug te gee; daarom verskyn die fout onmiddellik en sonder enige verkeer wat die masjien verlaat. Iemand, of een of ander outomatisering, het daardie roete doelbewus daar gesit.

Die roetetiese is nie uitruilbaar nie. Blackhole gooi die pakket sonder 'n fout aan die sender, prohibit gee EACCES terug, en unreachable gee EHOSTUNREACH terug. 'n VPN-hulp wat tydens herverbinding 'n sink-roete installeer, kan dus 'n uitbarsting host-unreachable-foute veroorsaak wat verdwyn sodra die tonnel op is, terwyl 'n blackhole-roete eerder stil tydverstrykings sou veroorsaak.

Deursoek alle tabelle vir die tipe voordat jy die afgeleë kant blameer. Die reël wat die tabel kies, maak net soveel saak soos die roete daarin, en 'n roete wat by die hoofdabel gevoeg is, sal nie 'n kliënt help wie se beleidsreël sy verkeer eldersheen stuur nie.

'n Dooie buur veroorsaak dieselfde fout op Ethernet

Wanneer die gekose roete 'n skakel-gateway gebruik, het aflewering 'n opgeloste skakellaagadres nodig. Die kern stuur 'n ARP- of IPv6-buuroproep, en as geen antwoord kom nie, kan die pakket nie omraam word nie. Die stuur misluk dan met EHOSTUNREACH, selfs al is die roete self geldig.

Die buurtabel noem die stadium. INCOMPLETE beteken 'n oplossing is nog aan die gang, FAILED beteken die laaste poging het geen antwoord gekry nie, en REACHABLE of STALE beteken die kern het 'n bruikbare adres. 'n FAILED-inskrywing vir die VPN-gateway is 'n plaaslike afleweringsprobleem, nie bewyse oor die verre kant van die tonnel nie.

Lees die inskrywing vir die werklike volgende hop, nie vir die afgeleë internetadres nie. 'n Afgeleë adres word gewoonlik deur 'n router bereik, so dit sal nie sy eie ARP-rekord hê nie; om een te vra is 'n kategorieëfout wat mense laat soek na 'n ontbrekende inskrywing wat nooit veronderstel was om te bestaan nie.

Afgeleë verslae en asinchrone UDP-foute

EHOSTUNREACH kan ook van buite kom. 'n Router wat die pakket nie kan aanstuur nie, stuur miskien ICMP host unreachable, en die kern gee daardie verslag deur aan die socket wat die stroom besit. In daardie geval is die roete en buur in orde, en die fout hoort by 'n hop anderkant die plaaslike netwerk.

UDP maak toeskrywing moeiliker. 'n Fout wat deur 'n latere stuur- of ontvang-oproep teruggegee word, kan na 'n vroeër datagram verwys, so die adres en tyd van die mislukkende oproep pas dalk nie by die pakket wat die verslag veroorsaak het nie. 'n Gekoppelde UDP-socket ontvang die fout een keer, en 'n ongekoppelde socket sien dit miskien nooit.

Daarom hoort tydsberekening by die bewyse. Let op wanneer die fout verskyn het, watter eweknie-adres die socket gebruik het, en of die tonnel pas weer gekoppel het. 'n Uitbarsting reg ná 'n roeteverandering wys na die plaaslike tabel; 'n enkele fout minute in 'n stabiele stroom wys na 'n padverslag.

Skei die lae voordat jy kripto verander

Drie vrae klassifiseer die fout. Het die kern 'n roete gekies wat die bestemming verwerp? Het hy 'n geldige roete gekies maar nie die volgende hop opgelos nie? Of het 'n verslag van anderkant die plaaslike netwerk gekom? Net die derde geval kan die verre kant van die tonnel betrek, en selfs dan nie die enkripsie nie.

Verifikasie- en onderhandelingsprobleme verskyn as hul eie foute nadat die vervoer die eweknie bereik. Om 'n syfer te verander of die kliënt te herinstalleer kan nie 'n plaaslike unreachable-roete regmaak nie, en dit vernietig die roete- en buurbewyse wat jy vir die werklike oorsaak sou nodig hê.

Teken die bestemming, naamruimte, gekose tabel, volgende hop, buurtoestand en fouttyd aan voor die eerste verandering. Herhaal dieselfde opsoek ná die regstelling; 'n roete wat nou na die tonnel wys en 'n buurinskrywing wat nou oplos, is sterker bewys as 'n suksesvolle ping na 'n onverwante adres.