Linux EHOSTUNREACH со OpenVPN: кој следен скок не успеа?

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

Резултатот од административна обвивка докажува само што би направила таа обвивка. Ако клиентот поставува ознака за огнен ѕид или се врзува за VRF, повторете го пребарувањето со соодветната ознака или внатре во VRF, и споредете ја избраната рута и следниот скок. Првата адреса што треба да се потврди е адресата на партнерот во профилот, не кластерот или услугата што ја наведува корисникот.

Експлицитна недостапна рута го одбива пакетот локално

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

Типовите рути не се заменливи. Blackhole го отфрла пакетот без грешка до испраќачот, prohibit враќа EACCES, а unreachable враќа EHOSTUNREACH. Затоа VPN помагач што инсталира понорна рута при повторно поврзување може да предизвика налет на host-unreachable грешки што исчезнуваат штом тунелот се подигне, додека blackhole рута наместо тоа би предизвикала тивки истекувања.

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

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

Кога избраната рута користи порта на врската, испораката бара решена адреса на слојот за врска. Јадрото испраќа ARP или IPv6 барање за сосед, и ако не пристигне одговор пакетот не може да се врами. Тогаш испраќањето не успева со EHOSTUNREACH иако самата рута е валидна.

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

Читајте го записот за вистинскиот следен скок, не за далечната интернет адреса. До далечна адреса обично се стигнува преку рутер, затоа таа нема да има сопствен ARP запис; да се бара еден е категорична грешка што ги праќа луѓето да бараат запис што никогаш не требало да постои.

Далечни извештаи и асинхрони UDP грешки

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

UDP го отежнува припишувањето. Грешка вратена од подоцнежен повик за испраќање или примање може да се однесува на поранешен датаграм, така што адресата и времето на повикот што не успева може да не се совпаѓаат со пакетот што го предизвикал извештајот. Поврзан UDP сокет ја добива грешката еднаш, а неповрзан сокет може никогаш да не ја види.

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

Одделете ги слоевите пред да ја промените криптографијата

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

Проблемите со автентикација и преговарање се појавуваат како сопствени грешки откако транспортот ќе го достигне партнерот. Промената на шифра или преинсталирањето на клиентот не може да поправи локална unreachable рута, и ги уништува доказите за рутата и соседот што би ви биле потребни за вистинската причина.

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