VPN cez viacero ciest: štyri záruky, ktoré musí operátor poskytnúť

Pridajte druhé WAN prepojenie a tunely sa zdvihnú, no kopírovanie súboru stále zamrzne, keď jedna cesta kolíše. Prepojenia sú zdravé a procesy VPN bežia; chýba zmluva medzi operátorom a tunelom. Viacero socketov sa automaticky nespráva ako jedno pripojenie a aplikácia nad nimi nevidí rozdiel, kým sa doručovanie nepreruší. Každá časť zmluvy zodpovedá zlyhaniu, ktoré môžete otestovať, a práve to ju robí užitočnou.

Napíšte túto zmluvu pred výberom produktu. Má štyri časti: tok, ktorý VPN prijíma, spôsob obnovy chýbajúcich dát operátorom, identitu koncového bodu, ktorá prežije zmenu cesty, a správanie celku, keď cesta zlyhá.

Príznak: prepojenia sú aktívne, relácia sa stále prerušuje

Graf monitorovania, ktorý ukazuje obe prepojenia aktívne, dokazuje len to, že každá cesta dokáže prenášať premávku. Nedokazuje, že VPN vidí jeden usporiadaný tok, že paket stratený na jednej ceste sa obnoví na inej, ani že partner ešte vie, s ktorou reláciou hovorí. Zvyšok zmluvy pokrýva to, čo graf nedokáže ukázať.

Keď sa prenos zasekne, zistite, či operátor pokračoval v doručovaní na prežívajúcej ceste. Ak relácia zomrie, kým je druhé prepojenie nečinné, operátor ho nikdy nepoužil. Ak relácia prežije, ale dáta prichádzajú mimo poradia alebo duplikovane, operátor presúva pakety bez zmluvy na úrovni pripojenia. Časové značky na oboch stranách to zvyčajne objasnia.

Tento rozdiel rozhoduje o oprave. Problém smerovania alebo politiky si vyžaduje zmenu výberu cesty; chýbajúca vrstva usporiadania a obnovy si vyžaduje iný transport, nie väčší buffer.

Prvá záruka: bajtový tok na úrovni pripojenia

Ak VPN potrebuje spoľahlivý usporiadaný tok, operátor musí identifikovať bajtové rozsahy nad jednotlivou cestou. Každé podkladové TCP pripojenie čísluje len svoje vlastné segmenty, takže príjemca nemôže meniť poradie medzi cestami iba pomocou týchto čísel.

Multipath TCP je štandardizovaný príklad. Ponúka jeden spoľahlivý bajtový tok pri koordinácii viacerých TCP podtokov, s mapovaním sekvencií a potvrdením na úrovni dát. Aplikácia číta tok, nie podtok, ktorý náhodou doručil kus ako prvý.

V Linuxe je MPTCP opt-in pre každý socket cez IPPROTO_MPTCP. Keď vyjednávanie nemôže použiť viaccestné správanie, dokumentovaným záložným riešením je bežný TCP, čo znamená, že aplikácia môže pokračovať po jednej ceste bez toho, aby niekedy použila druhú. Skontrolujte, aké správanie nasadený socket skutočne vyjednal, namiesto predpokladu, že sa uplatnilo nastavenie jadra.

Druhá záruka: usporiadanie, duplikácia a obnova

Cesty s rôznym oneskorením a mierou strát nútia operátora bufferovať, preusporadúvať a znova odosielať. Zmluva musí uviesť povolené bufferovanie, protitlak, ktorý aplikácia vidí, a to, ktorá cesta nesie opätovné odoslanie.

Cesta, ktorá zostane pripojená, ale prestane doručovať, je náročnejšia ako čisté zatvorenie. Operátor ju musí odhaliť, presunúť nevybavené dáta a vyhnúť sa večnému čakaniu na segment, ktorý nikdy nepríde. Jednoduchá kontrola, či sú obe prepojenia aktívne, tento stav nepokrýva.

Duplikácia potrebuje vlastné pravidlo. Odosielanie rovnakého obsahu po oboch cestách môže zlepšiť latenciu, ale príjemca musí kopiu potlačiť predtým, ako sa dostane do VPN. Anti-replay IPsec je voliteľný pre každé bezpečnostné združenie a kontroluje čísla sekvencií; vrstva duplikácie, ktorá preusporadúva alebo prehráva pakety, ho môže spustiť alebo skryť problém, kým tunel nespadne.

Tretia záruka: identita koncového bodu a pripojenie cesty

Partner potrebuje stabilný spôsob rozpoznania relácie, keď sa objaví nová cesta. Ak je každá cesta overená ako samostatný tunel, VPN môže vidieť dve relácie namiesto jednej. Ak operátor spája cesty pod jednu reláciu, musí definovať, ako sa nová cesta overuje a čo sa stane so starou.

Zapíšte, ktoré adresy a identifikátory zostávajú stabilné: koncový bod tunela, identifikátor relácie operátora a akýkoľvek proxy medzi nimi. Proxy pridáva ďalšiu hranicu dostupnosti a dôvery, aj keď nikdy nevidí chránený obsah.

Tu žije aj politika. Cesta pripájajúca sa z neočakávanej siete môže byť technicky platná a napriek tomu porušovať zamýšľaný model dôvery. Rozhodnite, či sa nové cesty prijímajú automaticky, vyžadujú overenie alebo sa odmietajú.

Štvrtá záruka: ohraničené správanie pri zlyhaní

Testujte úplné zlyhanie cesty, nielen pomalú cestu. Prežívajúca cesta by mala niesť reláciu bez neobmedzeného rastu pamäte a obnova by nemala závisieť od časovača dlhšieho, než aplikácia toleruje. Keď sa zlyhaná cesta vráti, operátor musí rozhodnúť, či vyrovná alebo nechá tok tam, kde je.

Nastavte limity bufferovania, opätovného odosielania a počtu ciest a potom ich overte pri strate, preusporiadaní, duplikácii a nerovnováhe oneskorenia. Celková šírka pásma je tu najmenej zaujímavé číslo; kontinuita doručovania a limity pamäte sú zmluvou.

Držte stav obnovy operátora oddelene od kryptografického stavu VPN. Vlastná vrstva spoľahlivosti, ktorá nahrádza zavedené overovanie alebo šifrovanie, nie je skratka a opätovné použitie čísel sekvencií medzi vrstvami robí ochranu proti prehratiu a diagnostiku nespoľahlivými.

Prijmite operátora s testovacím plánom

Napíšte štyri záruky ako kontroly prešlo alebo neprešlo: jeden usporiadaný tok, definovaná obnova, stabilná identita relácie, ohraničené správanie pri zlyhaní. Spustite každú kontrolu s jednou cestou zhoršenou a potom s jednou cestou odstránenou.

Jeden úspešný prenos súboru cez zmenu cesty nedokazuje nepretržitú prevádzku. Zopakujte prenos pri prepínaní preferovanej cesty a skontrolujte pohľad operátora aj vlastné počítadlá VPN. Ak sa obe nezhodujú v tom, ktorá cesta niesla dáta, zmluva ešte nie je pozorovateľná.

Uchovajte schválenú maticu s nasadením. Hovorí ďalšiemu inžinierovi, aké správanie bolo sľúbené, ktoré kombinácie ciest sa testovali a ktorý režim zlyhania zostáva nepodporovaný, bez ďalšieho kola hádania podľa svetiel stavu prepojení.