EHOSTUNREACH-ը հավասարապես հաճախ տեղական որոշում է, որքան հեռավոր խափանում։ Միջուկը կարող է մերժել փաթեթը, որովհետև երթուղին ասում է, թե նպատակակետն անհասանելի է, որովհետև Ethernet-ի հաջորդ ցատկը երբեք չպատասխանեց, կամ որովհետև ICMP host-unreachable զեկույց եկավ ուղու ավելի հեռու հատվածից։ Յուրաքանչյուր աղբյուր ապրում է տարբեր աղյուսակում կամ քեշում, և յուրաքանչյուրը շտկվում է տարբեր տեղում։ Կարդացեք ընտրված երթուղին և հաջորդ ցատկի վիճակը՝ նախքան գաղտնագրերին դիպչելը կամ թունելը վերատեղադրելը։

Ընտրեք այն հասցեն և անվանատարածքը, որոնք հաճախորդն իրականում օգտագործում է

Սկսեք ամրագրելով այն նպատակակետը և ցանցային անվանատարածքը, որոնք առաջացրել են սխալը։ VPN հաճախորդը կարող է աշխատել իր անվանատարածքում, և լռելյայն անվանատարածքից կատարված որոնումը դիմում է այլ երթուղային աղյուսակի՝ այլ քաղաքականության կանոններով։

Որոնումը պետք է օգտագործի նույն աղբյուրի, նշանի և աղյուսակի համատեքստը, ինչ ձախողվող հավելվածը, այլապես կարող է պատասխանել մի հարցի, որը ոչ ոք չի տվել։ Ցուցադրական IPv4 զուգընկերի համար միայն կարդալու ստուգումներն են՝

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

Վարչական shell-ից ստացված արդյունքը ապացուցում է միայն այն, թե այդ shell-ը ինչ կաներ։ Եթե հաճախորդը սահմանում է firewall նշան կամ կապվում է VRF-ին, կրկնեք որոնումը համապատասխան նշանով կամ VRF-ի ներսում, և համեմատեք ընտրված երթուղին ու հաջորդ ցատկը։ Առաջին հասցեն, որ պետք է հաստատել, պրոֆիլի զուգընկերի հասցեն է, ոչ թե այն կլաստերը կամ ծառայությունը, որը նշում է օգտատերը։

Բացահայտ անհասանելի երթուղին մերժում է փաթեթը տեղում

unreachable տիպի երթուղին դիտավորյալ տեղական պատասխան է։ Այն միջուկին ասում է դեն նետել փաթեթը և վերադարձնել EHOSTUNREACH-ը ուղարկողին, դրա համար էլ սխալը հայտնվում է ակնթարթորեն և առանց մեքենայից դուրս եկող ոչ մի երթևեկության։ Ինչ-որ մեկը կամ ինչ-որ ավտոմատացում դիտավորյալ դրել է այդ երթուղին այնտեղ։

Երթուղիների տիպերը փոխարինելի չեն։ Blackhole-ը դեն է նետում փաթեթը առանց ուղարկողին սխալ տալու, prohibit-ը վերադարձնում է EACCES, իսկ unreachable-ը՝ EHOSTUNREACH։ Այդ պատճառով VPN օգնականը, որը վերակապակցման ընթացքում տեղադրում է խորշային երթուղի, կարող է առաջացնել host-unreachable սխալների պոռթկում, որոնք անհետանում են թունելի բարձրանալուն պես, մինչդեռ blackhole երթուղին փոխարենը կստեղծեր լուռ ժամկետանցումներ։

Նախքան հեռավոր ծայրին մեղադրելը՝ փնտրեք տիպը բոլոր աղյուսակներում։ Աղյուսակն ընտրող կանոնը նույնքան կարևոր է, որքան դրա ներսում եղած երթուղին, և հիմնական աղյուսակին ավելացված երթուղին չի օգնի այն հաճախորդին, ում քաղաքականության կանոնը երթևեկնն ուղարկում է այլուր։

Մեռած հարևանը նույն սխալն է առաջացնում Ethernet-ում

Երբ ընտրված երթուղին օգտագործում է կապի վրա գտնվող դարպաս, առաքմանը պետք է լուծված կապուղու շերտի հասցե։ Միջուկը ուղարկում է ARP կամ IPv6 հարևանի հարցում, և եթե պատասխան չգա, փաթեթը հնարավոր չէ շրջանակել։ Այնուհետև ուղարկումը ձախողվում է EHOSTUNREACH-ով, թեև երթուղին ինքնին վավեր է։

Հարևանների աղյուսակը նշում է փուլը։ INCOMPLETE-ը նշանակում է, որ լուծումը դեռ ընթացքի մեջ է, FAILED-ը՝ որ վերջին փորձը պատասխան չի ստացել, իսկ REACHABLE-ը կամ STALE-ը՝ որ միջուկն ունի օգտագործելի հասցե։ VPN դարպասի համար FAILED գրառումը տեղական առաքման խնդիր է, ոչ թե ապացույց թունելի հեռավոր կողմի մասին։

Կարդացեք գրառումը փաստացի հաջորդ ցատկի համար, ոչ թե հեռավոր ինտերնետ հասցեի։ Հեռավոր հասցեին սովորաբար հասնում են երթուղիչի միջով, ուստի այն իր սեփական ARP գրառումը չի ունենա։ մեկը խնդրելը կարգաբանական սխալ է, որը մարդկանց ուղարկում է փնտրելու մի բացակայող գրառում, որը երբեք չպետք է լիներ։

Հեռավոր զեկույցներ և ասինխրոն UDP սխալներ

EHOSTUNREACH-ը կարող է գալ նաև դրսից։ Երթուղիչը, որը չի կարող փոխանցել փաթեթը, կարող է ուղարկել ICMP host unreachable, և միջուկը այդ զեկույցը փոխանցում է հոսքին պատկանող socket-ին։ Այդ դեպքում երթուղին և հարևանը կարգին են, և խափանումը պատկանում է տեղական ցանցից այն կողմ գտնվող ցատկի։

UDP-ն դժվարացնում է վերագրումը։ Ավելի ուշ send կամ receive կանչի վերադարձրած սխալը կարող է վերաբերել ավելի վաղ datagram-ի, ուստի ձախողվող կանչի հասցեն և ժամանակը կարող են չհամապատասխանել այն փաթեթին, որն առաջացրել է զեկույցը։ Միացված UDP socket-ը սխալը ստանում է մեկ անգամ, իսկ չմիացված socket-ը կարող է երբեք չտեսնել այն։

Այդ պատճառով ժամանակը ապացույցների մասն է։ Նշեք, երբ սխալը հայտնվեց, որ զուգընկերի հասցեն օգտագործեց socket-ը, և արդյոք թունելը նոր էր վերակապակցվել։ Երթուղու փոփոխությունից անմիջապես հետո պոռթկումը մատնանշում է տեղական աղյուսակին։ կայուն հոսքի մեջ մի քանի րոպե անց միայնակ սխալը՝ ուղու զեկույցին։

Առանձնացրեք շերտերը՝ նախքան գաղտնագրությունը փոխելը

Երեք հարց դասակարգում են սխալը։ Արդյոք միջուկն ընտրել է երթուղի, որը մերժում է նպատակակետը։ Արդյոք այն ընտրել է վավեր երթուղի, բայց չի կարողացել լուծել հաջորդ ցատկը։ Թե՞ զեկույց է եկել տեղական ցանցից այն կողմից։ Միայն երրորդ դեպքը կարող է ներառել թունելի հեռավոր ծայրը, և նույնիսկ այդ ժամանակ այն չի ներառում գաղտնագրումը։

Նույնականացման և բանակցության խնդիրները ի հայտ են գալիս որպես իրենց սեփական սխալներ այն բանից հետո, երբ տրանսպորտը հասնում է զուգընկերոջը։ Գաղտնագրի փոփոխությունը կամ հաճախորդի վերատեղադրումը չի կարող շտկել տեղական unreachable երթուղին, և այն ոչնչացնում է այն երթուղու և հարևանի ապացույցները, որոնք ձեզ պետք կգային իրական պատճառի համար։

Նախքան առաջին փոփոխությունը գրանցեք նպատակակետը, անվանատարածքը, ընտրված աղյուսակը, հաջորդ ցատկը, հարևանի վիճակը և սխալի ժամանակը։ Ուղղումից հետո նորից գործարկեք նույն որոնումը։ երթուղին, որն այժմ մատնանշում է թունելին, և հարևանի գրառումը, որն այժմ լուծվում է, ավելի ուժեղ ապացույց են, քան անկապ հասցեին հաջող ping-ը։

Առնչվող հոդվածներ