Чаму маршруты з роўным коштам робяць збоі 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. Запішыце, ці збой ідзе за пэўным наступным хопам, памерам пакета або пераходам пасля перападключэння, бо гэтыя тры заканамернасці паказваюць на розныя рамонты.
Нарэшце, запішыце, чаму шляхі лічацца эквівалентнымі і як збой павінен вывесці адзін з іх з эксплуатацыі. Шматадраснасць бяспечная толькі тады, калі шляхі сапраўды ўзаемазаменныя, і гэта праектнае сцвярджэнне варта праверыць, а не дапускаць.