Linux и EHOSTUNREACH са OpenVPN: који следећи скок је отказао?

EHOSTUNREACH је подједнако често локална одлука колико и удаљени отказ. Језгро може одбити пакет зато што рута каже да је одредиште недоступно, зато што Ethernet следећи скок никада није одговорио, или зато што је дуж пута стигао извештај ICMP host-unreachable. Сваки извор живи у другој табели или кешу, и сваки се исправља на другом месту. Прочитајте изабрану руту и стање следећег скока пре него што такнете шифре или поново инсталирате тунел.

Изаберите адресу и namespace које клијент заиста користи

Почните тако што ћете фиксирати одредиште и мрежни namespace који је произвео грешку. VPN клијент може радити у сопственом namespace-у, а претрага из подразумеваног консултује другу табелу рутирања са другачијим правилима политике.

Претрага мора користити исти извор, mark и контекст табеле као апликација која отказује, иначе може одговорити на питање које нико није поставио. За илустративни peer 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

Резултат из административне шкољке доказује само шта би та шкољка урадила. Ако клијент поставља firewall mark или се везује за VRF, поновите претрагу са одговарајућим mark-ом или унутар VRF-а и упоредите изабрану руту и следећи скок. Прва адреса коју треба потврдити је адреса peer-а у профилу, а не кластер или сервис који корисник именује.

Изричита недоступна рута одбија пакет локално

Рута типа unreachable је намерно локални одговор. Она каже језгру да одбаци пакет и врати пошиљаоцу EHOSTUNREACH, због чега се грешка појављује тренутно и без икаквог саобраћаја који напушта машину. Неко или нека аутоматизација је ту руту намерно поставила.

Типови рута нису заменљиви. blackhole одбацује пакет без грешке пошиљаоцу, prohibit враћа EACCES, а unreachable враћа EHOSTUNREACH. VPN помоћник који током поновног повезивања инсталира sink руту може зато произвести налет грешака host-unreachable које нестану кад се тунел подигне, док би blackhole рута уместо тога произвела тиха истека времена.

Пре него што окривите удаљени крај, претражите све табеле по типу. Правило које бира табелу важно је као и рута у њој, а рута додата у главну табелу неће помоћи клијенту чије правило политике шаље саобраћај другде.

Мртав сусед производи исту грешку на Ethernet-у

Када изабрана рута користи on-link мрежни пролаз, испорука захтева разрешену адресу слоја везе. Језгро шаље ARP или суседско питање IPv6, и ако одговор не стигне, пакет се не може уоквирити. Слање тада отказује са EHOSTUNREACH иако је сама рута исправна.

Суседска табела именује фазу. INCOMPLETE значи да је разрешавање још у току, FAILED значи да последњи покушај није добио одговор, а REACHABLE или STALE значи да језгро има употребљиву адресу. Унос FAILED за VPN пролаз је локални проблем испоруке, не доказ о удаљеној страни тунела.

Читајте унос за стварни следећи скок, не за удаљену интернет адресу. Удаљена адреса се обично достиже преко рутера, па неће имати сопствени ARP запис; тражити га је грешка категорије која шаље људе да траже недостајући унос који никада није требало да постоји.

Удаљени извештаји и асинхроне UDP грешке

EHOSTUNREACH може стићи и споља. Рутер који не може проследити пакет може послати ICMP host unreachable, а језгро прослеђује тај извештај сокету који поседује ток. У том случају рута и сусед су у реду, а отказ припада скоку иза локалне мреже.

UDP отежава утврђивање узрока. Грешка коју врати каснији позив send или receive може се односити на ранији датаграм, па се адреса и време позива који отказује можда не поклапају са пакетом који је извештај изазвао. Повезани UDP сокет прими грешку једном, а неповезани је можда никада не види.

Зато време припада доказима. Забележите када се грешка појавила, коју адресу peer-а је сокет користио и да ли се тунел управо поново повезао. Налет одмах после промене руте указује на локалну табелу; једна грешка минутима после стабилног тока указује на извештај пута.

Раздвојите слојеве пре него што промените криптографију

Три питања класификују грешку. Да ли је језгро изабрало руту која одбија одредиште? Да ли је изабрало исправну руту али није успело да разреши следећи скок? Или је извештај стигао иза локалне мреже? Само трећи случај може укључити удаљени крај тунела, и ни тада не укључује шифровање.

Проблеми са аутентификацијом и преговарањем појављују се као сопствене грешке након што транспорт стигне до peer-а. Промена шифре или поновна инсталација клијента не може поправити локалну недоступну руту и уништава доказе о рути и суседу који би вам требали за прави узрок.

Забележите одредиште, namespace, изабрану табелу, следећи скок, стање суседа и време грешке пре прве промене. Покрените исту претрагу после исправке; рута која сада показује на тунел и суседски унос који се сада разрешава јачи су доказ од успешног ping-а на неповезану адресу.