Зашто руте са једнаком ценом чине кварове 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-ове. Забележите прати ли квар одређени следећи скок, величину пакета или прелаз након поновног повезивања, јер та три обрасца упућују на различите поправке.
На крају запишите зашто се путеви сматрају еквивалентним и како би квар требало да избаци један од њих из употребе. Вишепутост је безбедна само када су путеви доиста заменљиви, а то је пројектна тврдња коју вреди проверити, а не претпоставити.