Linux EHOSTUNREACH mei OpenVPN: hokker folgjende hop mislearre?
EHOSTUNREACH kin komme fan in eksplisite ûnberikbere rûte, in deade buorman of in ferslach fan fierrens. Lês de keazen rûte en de folgjende hop foardat jo kryptografy oanreitsje.
EHOSTUNREACH is like faak in lokale beslissing as in ferslach fan fierrens. De kernel kin in pakket wegerje om't in rûte seit dat de bestimming ûnberikber is, om't de Ethernet-folgjende hop nea antwurde, of om't in ICMP host-unreachable-ferslach fan fierder lâns it paad oankaam. Eltse boarne libbet yn in oare tabel of cache, en elk wurdt op in oar plak reparearre. Lês de keazen rûte en de tastân fan de folgjende hop foardat jo sifers oanreitsje of de tunnel opnij ynstallearje.
Kies it adres en de nammeromte dy't de klant eins brûkt
Begjin mei it fêstlizzen fan de bestimming en de netwurk-nammeromte dy't de flater makke. In VPN-klant kin yn syn eigen nammeromte rinne, en in syktocht fan 'e standert-nammeromte rieplachtet in oare rûtetabel mei oare beliedsregels.
De syktocht moat deselde boarne-, merke- en tabelkontekst brûke as de flaterjende applikaasje, oars beantwurdet it miskien in fraach dy't nimmen stelde. Foar in yllustrative IPv4-pear binne de lês-allinnich-kontrôles:
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
In resultaat út in administratieve shell bewiist allinnich wat dy shell dwaan soe. As de klant in firewallmerke set of him oan in VRF bûn, werhelje de syktocht mei de oerienkommende merke of binnen de VRF, en fergelykje de keazen rûte en de folgjende hop. It earste adres dat befêstige wurde moat, is it pearadres yn it profyl, net it cluster of de tsjinst dy't de brûker neamt.
In eksplisite ûnberikbere rûte wegeret it pakket lokaal
In rûte fan it type unreachable is in bewuste lokale antwurd. It seit tsjin de kernel om it pakket fuort te smiten en EHOSTUNREACH oan 'e ôfstjoerder werom te jaan, dêrom ferskynt de flater daliks en sûnder ferkear dat de masine ferlit. Immen, of ien of oare automatisearring, hat dy rûte dêr mei opsetsin pleatst.
De rûtetypen binne net útwikselber. Blackhole smyt it pakket fuort sûnder flater oan 'e ôfstjoerder, prohibit jout EACCES werom, en unreachable jout EHOSTUNREACH werom. In VPN-help dy't by it opnij ferbinen in sink-rûte ynstallearret, kin dêrom in weach host-unreachable-flaters meitsje dy't ferdwine sadree't de tunnel omheech is, wylst in blackhole-rûte ynstee stille time-outs meitsje soe.
Sykje alle tabellen foar it type ôf foardat jo de fiere ein de skuld jouwe. De regel dy't de tabel kiest, jildt likefolle as de rûte deryn, en in rûte dy't oan 'e haadtabel taheakke is, sil in klant net helpe waans beliedsregel syn ferkear earne oars hinne stjoert.
In deade buorman makket deselde flater op Ethernet
As de keazen rûte in on-link-gateway brûkt, hat levering in oplost keppellaachadres nedich. De kernel stjoert in ARP- of IPv6-buormanfraach, en as der gjin antwurd komt, kin it pakket net oanfreame wurde. It stjoeren mislearret dan mei EHOSTUNREACH, ek al is de rûte sels jildich.
De buormentabel neamt de faze. INCOMPLETE betsjut dat in oplossing noch geande is, FAILED betsjut dat de lêste poging gjin antwurd krige, en REACHABLE of STALE betsjut dat de kernel in brûkber adres hat. In FAILED-ynfier foar de VPN-gateway is in lokaal leveringsprobleem, net bewiis oer de fiere kant fan 'e tunnel.
Lês de ynfier foar de werklike folgjende hop, net foar it fiere ynternetadres. In fier adres wurdt normaal fia in router berikt, dus it sil gjin eigen ARP-record hawwe; om ien freegje is in kategoryflater dy't minsken sykje lit nei in ûntbrekkende ynfier dy't nea bestean moatten hie.
Ferslaggen fan fierrens en asynkrone UDP-flaters
EHOSTUNREACH kin ek fan bûten komme. In router dy't it pakket net trochstjoere kin, stjoert miskien ICMP host unreachable, en de kernel jout dat ferslach troch oan de socket dy't de stream hat. Yn dat gefal binne de rûte en de buorman yn oarder, en heart de flater by in hop foarby it lokale netwurk.
UDP makket taskriuwjen dreger. In flater dy't troch in lettere stjoer- of ûntfangstoprop werombrocht wurdt, kin op in eardere datagram slaan, sadat it adres en de tiid fan 'e mislearjende oprop miskien net by it pakket passe dat it ferslach útlokke. In ferbûn UDP-socket krijt de flater ien kear, en in net-ferbûn socket sjocht him miskien nea.
Dêrom heart timing by it bewiis. Notearje wannear't de flater ferskynde, hokker pearadres de socket brûkte, en oft de tunnel krekt opnij ferbûn wie. In weach fuort nei in rûteferoaring wiist nei de lokale tabel; in inkelde flater minuten yn in stabile stream wiist nei in paadferslach.
Skied de lagen foardat jo krypto feroarje
Trije fragen klassifisearje de flater. Hat de kernel in rûte keazen dy't de bestimming wegeret? Hat er in jildige rûte keazen mar de folgjende hop net oplost? Of kaam der in ferslach fan foarby it lokale netwurk? Allinnich it tredde gefal kin de fiere ein fan 'e tunnel belûke, en sels dan net de fersifering.
Autentikaasje- en ûnderhannelingsproblemen ferskine as har eigen flaters neidat it ferfier it pear berikt. In sifer feroarje of de klant opnij ynstallearje kin in lokale unreachable-rûte net reparearje, en it ferneatiget it rûte- en buormanbewiis dat jo foar de echte oarsaak nedich hawwe soene.
Registrearje de bestimming, nammeromte, keazen tabel, folgjende hop, buormantastân en flatertiid foar de earste feroaring. Rin deselde syktocht opnij nei de reparaasje; in rûte dy't no nei de tunnel wiist en in buormanynfier dy't no oplost, binne sterker bewiis as in slagge ping nei in ûnbesibbe adres.