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 да недатычнага адраса.