Linux EHOSTUNREACH pamoja na OpenVPN: ni hatua gani iliyofuata ilishindikana?

EHOSTUNREACH mara nyingi ni uamuzi wa ndani kama vile ni kushindikana kwa mbali. Kernel inaweza kukataa pakiti kwa sababu njia inasema lengo haliwezi kufikiwa, kwa sababu hatua inayofuata ya Ethernet haikujibu kamwe, au kwa sababu ripoti ya ICMP host-unreachable ilifika kutoka mbele zaidi kwenye njia. Kila chanzo huishi kwenye jedwali au akiba tofauti, na kila kimoja hurekebishwa mahali tofauti. Soma njia iliyochaguliwa na hali ya hatua inayofuata kabla ya kugusa cipher au kusakinisha tena handaki.

Chagua anwani na namespace ambayo mteja anaitumia kwa kweli

Anza kwa kubainisha lengo na namespace ya mtandao iliyozalisha hitilafu. Mteja wa VPN anaweza kukimbia kwenye namespace yake mwenyewe, na utafutaji kutoka ile ya kawaida hutumia jedwali lingine la njia lenye kanuni tofauti za sera.

Utafutaji lazima utumie chanzo, mark na muktadha wa jedwali sawa na programu inayoshindikana, vinginevyo unaweza kujibu swali ambalo hakuna aliyeliuliza. Kwa peer ya IPv4 ya mfano, ukaguzi wa kusoma tu ni:

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

Tokeo kutoka kwa shell ya msimamizi linathibitisha tu kile ambacho shell hiyo ingefanya. Ikiwa mteja anaweka firewall mark au anafungwa kwenye VRF, rudia utafutaji kwa mark inayolingana au ndani ya VRF, na linganisha njia iliyochaguliwa na hatua inayofuata. Anwani ya kwanza ya kuthibitisha ni anwani ya peer iliyo kwenye profile, si kundi au huduma anayoitaja mtumiaji.

Njia ya unreachable iliyo wazi hukataa pakiti ndani ya mashine

Njia ya aina ya unreachable ni jibu la ndani lililokusudiwa. Inaiambia kernel itupe pakiti na imrudishie mtumaji EHOSTUNREACH, ndiyo sababu hitilafu huonekana papo hapo na bila trafiki yoyote kuondoka kwenye mashine. Mtu, au otomatiki fulani, aliweka njia hiyo hapo kwa makusudi.

Aina za njia hazibadilishani. blackhole hutupa pakiti bila hitilafu kwa mtumaji, prohibit hurudisha EACCES, na unreachable hurudisha EHOSTUNREACH. Msaidizi wa VPN anayesakinisha njia ya sink wakati wa kuunganisha tena anaweza hivyo kuzalisha mlipuko wa hitilafu za host-unreachable zinazotoweka mara handaki linapoinuka, wakati njia ya blackhole ingezalisha badala yake muda wa kusubiri wa kimya.

Tafuta aina hiyo kwenye majedwali yote kabla ya kulaumu upande wa mbali. Kanuni inayochagua jedwali ni muhimu kama njia iliyo ndani yake, na njia iliyoongezwa kwenye jedwali kuu haitamsaidia mteja ambaye kanuni yake ya sera inapeleka trafiki mahali pengine.

Jirani aliyekufa huzalisha hitilafu hiyo hiyo kwenye Ethernet

Wakati njia iliyochaguliwa inatumia lango la on-link, uwasilishaji unahitaji anwani ya tabaka la kiungo iliyotatuliwa. Kernel hutuma ARP au ombi la jirani la IPv6, na ikiwa jibu halifiki pakiti haiwezi kuwekwa kwenye fremu. Utumaji kisha hushindikana kwa EHOSTUNREACH ingawa njia yenyewe ni sahihi.

Jedwali la majirani hutaja hatua. INCOMPLETE inamaanisha utatuzi bado unaendelea, FAILED inamaanisha jaribio la mwisho halikupata jibu, na REACHABLE au STALE inamaanisha kernel ina anwani inayoweza kutumika. Kipengele cha FAILED kwa lango la VPN ni tatizo la uwasilishaji wa ndani, si ushahidi kuhusu upande wa mbali wa handaki.

Soma kipengele cha hatua inayofuata halisi, si cha anwani ya mbali ya intaneti. Anwani ya mbali kwa kawaida hufikiwa kupitia router, kwa hiyo haitakuwa na rekodi yake ya ARP; kuiomba ni hitilafu ya aina inayowapeleka watu kutafuta kipengele kilichopotea ambacho hakikupaswa kuwepo kamwe.

Ripoti za mbali na hitilafu za UDP zisizo za samtidiga

EHOSTUNREACH inaweza pia kufika kutoka nje. Router isiyoweza kusambaza pakiti inaweza kutuma ICMP host unreachable, na kernel hupeleka ripoti hiyo kwa socket inayomiliki mtiririko. Katika hali hiyo njia na jirani ni sawa, na kushindikana ni kwa hatua iliyo ng'ambo ya mtandao wa ndani.

UDP hufanya utambuzi kuwa mgumu. Hitilafu inayorudishwa na wito wa send au receive wa baadaye inaweza kurejelea datagram ya awali, kwa hiyo anwani na muda wa wito unaoshindikana huenda visilingane na pakiti iliyochochea ripoti. Socket ya UDP iliyounganishwa hupokea hitilafu mara moja, na socket isiyounganishwa huenda isiione kamwe.

Ndiyo sababu muda ni sehemu ya ushahidi. Andika wakati hitilafu ilipoonekana, ni anwani gani ya peer socket ilitumia, na kama handaki lilikuwa limetoka kuunganishwa tena. Mlipuko papo hapo baada ya mabadiliko ya njia huelekea jedwali la ndani; hitilafu moja dakika chache ndani ya mtiririko thabiti huelekea ripoti ya njia.

Tenganisha tabaka kabla ya kubadilisha crypto

Maswali matatu huiainisha hitilafu. Kernel ilichagua njia inayokataa lengo? Ilichagua njia sahihi lakini ikashindwa kutatuwa hatua inayofuata? Au ripoti ilifika kutoka ng'ambo ya mtandao wa ndani? Ni kesi ya tatu pekee inayoweza kuhusisha upande wa mbali wa handaki, na hata hivyo haihusishi usimbaji fiche.

Matatizo ya uthibitishaji na majadiliano hujitokeza kama hitilafu zao wenyewe baada ya usafirishaji kufikia peer. Kubadilisha cipher au kusakinisha tena mteja hakuwezi kurekebisha njia ya unreachable ya ndani, na huharibu ushahidi wa njia na jirani ambao ungeuhitaji kwa sababu halisi.

Andika lengo, namespace, jedwali lililochaguliwa, hatua inayofuata, hali ya jirani na muda wa hitilafu kabla ya mabadiliko ya kwanza. Rudia utafutaji huo huo baada ya marekebisho; njia inayoelekea handaki sasa na kipengele cha jirani kinachotatuliwa sasa ni ushahidi madhubuti kuliko ping iliyofanikiwa kwa anwani isiyohusiana.