Ինչու հավասար արժեքով երթուղիները 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-երը։ Գրանցեք՝ արդյոք խափանումը հետևում է որոշակի հաջորդ ցատկի, փաթեթի չափի կամ վերամիացումից հետո անցման, քանի որ այդ երեք օրինաչափությունները մատնանշում են տարբեր վերանորոգումներ։
Վերջում գրեք, թե ինչու են ուղիները համարվում համարժեք և ինչպես պետք է խափանումը մեկին հանի ծառայությունից։ Բազմուղին անվտանգ է միայն այն ժամանակ, երբ ուղիներն իսկապես փոխարինելի են, և սա նախագծային պնդում է, որն արժե ստուգել, այլ ոչ թե ենթադրել։