Эмне үчүн бирдей баадагы маршруттар VPN бузулууларын байкоону кыйындатат
Бир нече туннель бирдей бааны бөлүшкөндө, ар бир агым башкасын тандай алат. Ийгиликтүү ping колдонмосуңуз чындыгында колдонгон жол тууралуу эч нерсе айтпайт.
Колдонуучу ички колдонмо бир машинадан иштеп, экинчисинен иштебей жатканын билдирет, ал эми дарбазадан иштетилген ping эки учурда тең ийгиликтүү. Бирдей баадагы бир нече туннель болгондо бул карама-каршылык эмес. Ар бир агым өзүнүн кийинки секирүүсүнө жайгаштырылат, ошондуктан сиздин текшерүүңүз менен колдонуучунун сессиясы жөн гана башка жолдорду колдонушу мүмкүн. Төмөнкү сереп бир нерсени өзгөртүүдөн мурун ушул тандоону кайра жаратат.
Бир ping, бир нече мүмкүн болгон жол
Маршрутта бирдей баада бирден ашык кийинки секирүү болсо, маршрутизатор ар бир пакет үчүн бирин тандашы керек. Көпчүлүк ишке ашыруулар пакеттин талааларын хэштейт, адатта булак жана багыт даректерин протокол жана порттор менен кошо, жооптор ошол эле жолдо калышы үчүн. Ар кандай колдонмолор, атүгүл бир колдонмонун ар кандай туташуулары ар кандай хэштерди жаратат.
Ошондуктан дарбазадан жасалган диагностика ушунча аз далилдейт. Дарбазанын өз текшерүүсүнүн өз даректери жана порттору, демек өз хэши бар. Ал соо туннелге конушу мүмкүн, ал эми колдонуучу бузулган туннелге коно берет.
Платформа кийинки секирүүнү кантип тандайт
Тандоону болжолдоонун ордуна кайра жаратыңыз. Ядродон ийгиликсиз сессиядагыдай эле булак жана багыт үчүн кайсы маршрутту колдонорун сураңыз. Бул издөө жөнөкөй багыт издөөсү этибарга албаган талааларды камтыйт. Аны иштеп жаткан клиенттен да иштетип, эки жоопту салыштырыңыз:
ip route get 10.20.5.7 from 10.20.0.14iproute2нин жаңы чыгарылыштары протокол менен багыт портун да кабыл алат, бул хэш аларды камтыганда маанилүү. Ошол чыгарылышты иштеп жаткан клиенттен жасалган ошол эле издөө менен салыштырыңыз, ал эми айырма — сизге жетпеген далил.
| 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 |
Ийгиликсиз агымды ээрчиңиз, маршрут таблицасын эмес
Маршрут таблицасы эки туннелди тең тизмелеп, аныктама боюнча туура көрүнөт. Суроо — тандалгандан кийин ар бир туннель пакет менен эмне кылат. Экөө тең бирдей корголгон префикстерди, бирдей өткөрүү укугун жана ошол эле клиентке жеткен кайтаруу жолун алып жүргөнүн текшериңиз.
Ортодогу абалды сактаган түзмөктөргө көңүл буруңуз. Эгер суроо бир туннелден чыгып, жооп экинчисинен кайтса, анда баштапкы агымды эч качан көрбөгөн firewall же NAT аны таштайт. Эки туннель тең трафикти туура өткөрөт, ал эми байланыш баары бир ийгиликсиз болот.
Ар бир жол үчүн MTUну да текшериңиз. Кошумча инкапсуляциясы бар жол колдонууга боло турган өлчөмдү кичирейтип, бир туннелде ийгиликтүү өткөн өткөрмө экинчисинде кичинекейи сынган так ошол өлчөмдө токтойт.
Бир жолду бир убакта салыштырыңыз
Долбоор тейлөөгө жол берген жерде бир туннелди кызматтан чыгарып, колдонуучунун тапшырмасын кайталаңыз. Эгер бузулуу жоголсо, маселе сиз алган жолго таандык, кийинки кадам — маршруттоо таблицасын кайра кароонун ордуна анын конфигурациясын коңшусу менен салыштыруу.
Кайталанма ping эмес, чыныгы колдонмону салыштырыңыз. Бузулуу белгилүү бир кийинки секирүүгө, пакет өлчөмүнө же кайра туташкандан кийинки өтүүгө ээрчип жатканын жазыңыз, анткени бул үч үлгү ар башка оңдоолорду көрсөтөт.
Акырында жолдор эмне үчүн эквивалент деп эсептелээрин жана бузулуу алардын бирин кызматтан кантип чыгарышы керектигин жазыңыз. Көп жолдуулук жолдор чынында алмаштырыла турган болгондо гана коопсуз, жана бул божомолдоого эмес, текшерүүгө татыктуу долбоордук ырастоо.