Kodėl vienodos kainos maršrutai sunkina VPN gedimų pastebėjimą
Kai keli tuneliai dalijasi ta pačia kaina, kiekvienas srautas gali pasirinkti kitą. Sėkmingas ping nieko nesako apie kelią, kurį jūsų programa iš tikrųjų naudoja.
Naudotojas praneša, kad vidinė programa veikia iš vieno kompiuterio ir nepavyksta iš kito, o ping, kurį paleidžiate iš tinklo vartų, pavyksta abiem atvejais. Esant keliems vienodos kainos tuneliams, tai ne prieštaravimas. Kiekvienas srautas padedamas ant savo kito šuolio, todėl jūsų patikra ir naudotojo sesija gali tiesiog naudoti skirtingus kelius. Toliau pateikta eiga atkuria šį pasirinkimą prieš ką nors keičiant.
Vienas ping, keli galimi keliai
Kai maršrutas turi daugiau nei vieną kitą šuolį ta pačia kaina, maršrutizatorius turi pasirinkti vieną kiekvienam paketui. Dauguma implementacijų maišo paketo laukus, paprastai šaltinio ir paskirties adresus kartu su protokolu ir prievadais, kad atsakymai liktų tame pačiame kelyje. Skirtingos programos, net skirtingi vienos programos ryšiai, sukuria skirtingas maišas.
Štai kodėl diagnostika iš tinklo vartų įrodo taip mažai. Pačių vartų patikra turi savo adresus ir prievadus, taigi ir savo maišą. Ji gali nusileisti ant sveiko tunelio, kol naudotojas vis nusileidžia ant sugedusio.
Kaip platforma pasirenka kitą šuolį
Atkurkite pasirinkimą, o ne spėkite jį. Paklauskite branduolio, kokį maršrutą jis naudotų tam pačiam šaltiniui ir paskirčiai kaip nepavykstanti sesija. Ši paieška apima laukus, kurių paprasta paskirties paieška nepaiso. Paleiskite ją ir iš veikiančio kliento bei palyginkite du atsakymus:
ip route get 10.20.5.7 from 10.20.0.14Naujesni iproute2 leidimai taip pat priima protokolą ir paskirties prievadą, o tai svarbu, kai maiša juos apima. Palyginkite tą išvestį su ta pačia paieška iš veikiančio kliento, ir skirtumas yra įrodymas, kurio jums trūko.
| 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 |
Sekite nepavykstantį srautą, o ne maršrutų lentelę
Maršrutų lentelė išvardija abu tunelius ir pagal apibrėžimą atrodo teisinga. Klausimas, ką kiekvienas tunelis daro su paketu, kai jis pasirenkamas. Patikrinkite, ar abu neša tuos pačius apsaugotus prefiksus, tą patį persiuntimo leidimą ir grįžimo kelią, pasiekiantį tą patį klientą.
Atkreipkite dėmesį į būsenos įrenginius viduryje. Jei užklausa išeina per vieną tunelį, o atsakymas grįžta per kitą, ugniazė arba NAT, kuris niekada nematė pradinio srauto, ją numes. Abu tuneliai teisingai persiunčia srautą, o ryšys vis tiek nutrūksta.
Patikrinkite ir MTU kiekvienam keliui. Kelias su papildoma inkapsuliacija sumažina naudingą dydį, o perdavimas, kuris pavyksta vienu tuneliu, kitame sustoja būtent ties tuo dydžiu, kai mažesnis lūžta.
Palyginkite vieną kelią vienu metu
Kur projektas leidžia techninę priežiūrą, išimkite vieną tunelį iš tarnybos ir pakartokite naudotojo užduotį. Jei gedimas dingsta, problema priklauso pašalintam keliui, o kitas žingsnis yra palyginti jo konfigūraciją su kaimyno, o ne iš naujo nagrinėti maršrutizavimo lentelę.
Palyginkite tikrąją programą, o ne pakartotinius ping. Užrašykite, ar gedimas seka tam tikrą kitą šuolį, paketo dydį ar perėjimą po prisijungimo iš naujo, nes šie trys modeliai rodo skirtingus remontus.
Galiausiai užrašykite, kodėl keliai laikomi lygiaverčiais ir kaip gedimas turėtų išimti vieną iš jų iš tarnybos. Daugiatakis režimas saugus tik tada, kai keliai tikrai keičiami, ir tai yra projektinis teiginys, kurį verta patikrinti, o ne daryti prielaidą.