Защо маршрутите с еднаква цена правят неизправностите на VPN трудно видими
Когато няколко тунела споделят една цена, всеки поток може да поеме по различен. Успешен ping не казва нищо за пътя, който приложението ви действително използва.
Потребител съобщава, че вътрешното приложение работи от една машина и се проваля от друга, а ping, който пускате от шлюза, успява и в двата случая. При няколко тунела с еднаква цена това не е противоречие. Всеки поток се поставя на свой следващ хоп, така че вашата проверка и сесията на потребителя може просто да използват различни пътища. Разборът по-долу възпроизвежда избора, преди да се промени нещо.
Един ping, няколко възможни пътя
Когато маршрутът има повече от един следващ хоп с еднаква цена, рутерът трябва да избере един за всеки пакет. Повечето реализации хешират полета от пакета, обикновено адресите на източника и дестинацията заедно с протокола и портовете, за да останат отговорите на същия път. Различните приложения, дори различните връзки от едно приложение, дават различни хешове.
Ето защо диагностика от шлюза доказва толкова малко. Собствената проверка на шлюза има свои адреси и портове, а следователно и свой хеш. Тя може да попадне на здравия тунел, докато потребителят продължава да попада на счупения.
Как платформата избира следващ хоп
Възпроизведете избора, вместо да го гадаете. Попитайте ядрото кой маршрут би използвало за същите източник и дестинация като при неуспешната сесия. Тази проверка включва полета, които обикновеното търсене по дестинация пренебрегва. Изпълнете я и от работещ клиент и сравнете двата отговора:
ip route get 10.20.5.7 from 10.20.0.14По-новите издания на iproute2 приемат също протокола и порта на дестинацията, което има значение, когато хешът ги включва. Сравнете този изход със същата проверка от работещ клиент и разликата е доказателството, което ви липсваше.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
Проследете неуспешния поток, а не таблицата с маршрути
Таблицата с маршрути изброява двата тунела и по определение изглежда вярна. Въпросът е какво прави всеки тунел с пакета, след като бъде избран. Проверете дали и двата носят едни и същи защитени префикси, същото разрешение за препращане и обратен път, който достига до същия клиент.
Обърнете внимание на устройствата със състояние по средата. Ако заявка излезе през единия тунел, а отговорът се върне през другия, защитна стена или NAT, които никога не са видели първоначалния поток, ще го отхвърлят. Двата тунела препращат трафик правилно, а връзката все пак се проваля.
Проверете също MTU по всеки път. Път с допълнителна инкапсулация свива използваемия размер и трансфер, който успява по единия тунел, засича по другия точно при размера, при който по-малкият се чупи.
Сравнявайте по един път наведнъж
Където дизайнът позволява обслужване, извадете единия тунел от експлоатация и повторете задачата на потребителя. Ако неизправността изчезне, проблемът е в премахнатия път и следващата стъпка е да сравните конфигурацията му със съседния, а не да преглеждате отново таблицата с маршрути.
Сравнявайте реалното приложение, а не повтарящи се ping. Запишете дали неизправността следва определен следващ хоп, размер на пакета или преход след повторно свързване, защото тези три модела сочат към различни поправки.
Накрая запишете защо пътищата се смятат за еквивалентни и как неизправност трябва да извади един от тях от експлоатация. Многопътността е безопасна само когато пътищата наистина са взаимозаменяеми и това е проектно твърдение, което си струва да се провери, вместо да се приема.