VPN přes více cest: čtyři záruky, které musí operátor poskytnout

Přidejte druhé propojení WAN a tunely se zvednou, ale kopírování souboru stále zamrzne, když jedna cesta kolísá. Propojení jsou zdravá a procesy VPN běží; chybí smlouva mezi operátorem a tunelem. Několik socketů se automaticky nechová jako jedno připojení a aplikace nad nimi rozdíl nevidí, dokud se doručování nepřeruší. Každá část smlouvy odpovídá selhání, které můžete otestovat, a právě to ji činí užitečnou.

Napište tuto smlouvu před výběrem produktu. Má čtyři části: tok, který VPN přijímá, způsob obnovy chybějících dat operátorem, identitu koncového bodu, která přežije změnu cesty, a chování celku, když cesta selže.

Příznak: propojení jsou aktivní, relace se stále přerušuje

Graf monitorování, který ukazuje obě propojení aktivní, dokazuje jen to, že každá cesta dokáže přenášet provoz. Nedokazuje, že VPN vidí jeden uspořádaný tok, že paket ztracený na jedné cestě se obnoví na jiné, ani že partner ještě ví, se kterou relací mluví. Zbytek smlouvy pokrývá to, co graf nedokáže ukázat.

Když se přenos zasekne, zjistěte, zda operátor pokračoval v doručování na přežívající cestě. Pokud relace zemře, zatímco je druhé propojení nečinné, operátor ho nikdy nepoužil. Pokud relace přežije, ale data přicházejí mimo pořadí nebo duplikovaně, operátor přesouvá pakety bez smlouvy na úrovni připojení. Časová razítka na obou stranách to obvykle objasní.

Tento rozdíl rozhoduje o opravě. Problém směrování nebo politiky vyžaduje změnu volby cesty; chybějící vrstva řazení a obnovy vyžaduje jiný transport, ne větší buffer.

První záruka: bajtový tok na úrovni připojení

Pokud VPN potřebuje spolehlivý uspořádaný tok, operátor musí identifikovat bajtové rozsahy nad jednotlivou cestou. Každé podkladové připojení TCP čísluje pouze své vlastní segmenty, takže příjemce nemůže měnit pořadí mezi cestami pouze pomocí těchto čísel.

Multipath TCP je standardizovaný příklad. Nabízí jeden spolehlivý bajtový tok při koordinaci několika podtoků TCP, s mapováním sekvencí a potvrzením na úrovni dat. Aplikace čte tok, ne podtok, který náhodou doručil kus jako první.

V Linuxu je MPTCP opt-in pro každý socket přes IPPROTO_MPTCP. Když vyjednávání nemůže použít vícesměrové chování, dokumentovanou záložní možností je běžný TCP, což znamená, že aplikace může pokračovat po jedné cestě, aniž by kdy použila druhou. Zkontrolujte, jaké chování nasazený socket skutečně vyjednal, místo abyste předpokládali, že se uplatnilo nastavení jádra.

Druhá záruka: řazení, duplikace a obnova

Cesty s různým zpožděním a mírou ztrát nutí operátora bufferovat, přeuspořádávat a znovu odesílat. Smlouva musí uvést povolené bufferování, protitlak, který aplikace vidí, a to, která cesta nese opětovné odeslání.

Cesta, která zůstane připojená, ale přestane doručovat, je obtížnější než čisté zavření. Operátor ji musí odhalit, přesunout nevyřízená data a vyhnout se věčnému čekání na segment, který nikdy nedorazí. Jednoduchá kontrola, zda jsou obě propojení aktivní, tento stav nepokrývá.

Duplikace potřebuje vlastní pravidlo. Odesílání stejného obsahu po obou cestách může zlepšit latenci, ale příjemce musí kopii potlačit, než se dostane do VPN. Anti-replay IPsec je volitelný pro každé bezpečnostní sdružení a kontroluje čísla sekvencí; vrstva duplikace, která přeuspořádává nebo přehrává pakety, ho může spustit nebo skrýt problém, dokud tunel nespadne.

Třetí záruka: identita koncového bodu a připojení cesty

Partner potřebuje stabilní způsob rozpoznání relace, když se objeví nová cesta. Pokud je každá cesta ověřena jako samostatný tunel, VPN může vidět dvě relace místo jedné. Pokud operátor spojuje cesty pod jednu relaci, musí definovat, jak se nová cesta ověřuje a co se stane se starou.

Zapište, které adresy a identifikátory zůstávají stabilní: koncový bod tunelu, identifikátor relace operátora a případný proxy mezi nimi. Proxy přidává další hranici dostupnosti a důvěry, i když nikdy nevidí chráněný obsah.

Zde žije i politika. Cesta připojující se z neočekávané sítě může být technicky platná a přesto porušovat zamýšlený model důvěry. Rozhodněte, zda se nové cesty přijímají automaticky, vyžadují ověření, nebo se odmítají.

Čtvrtá záruka: omezené chování při selhání

Testujte úplné selhání cesty, nejen pomalou cestu. Přežívající cesta by měla nést relaci bez neomezeného růstu paměti a obnova by neměla záviset na časovači delším, než aplikace toleruje. Když se selhavší cesta vrátí, operátor musí rozhodnout, zda vyrovná, nebo nechá tok tam, kde je.

Nastavte limity bufferování, opětovného odesílání a počtu cest a poté je ověřte při ztrátě, přeuspořádání, duplikaci a nerovnováze zpoždění. Celková šířka pásma je zde nejméně zajímavé číslo; kontinuita doručování a limity paměti jsou smlouvou.

Držte stav obnovy operátora odděleně od kryptografického stavu VPN. Vlastní vrstva spolehlivosti, která nahrazuje zavedené ověřování nebo šifrování, není zkratkou a opětovné použití čísel sekvencí mezi vrstvami činí ochranu proti přehrání a diagnostiku nespolehlivými.

Přijměte operátora s testovacím plánem

Napište čtyři záruky jako kontroly prošlo nebo neprošlo: jeden uspořádaný tok, definovaná obnova, stabilní identita relace, omezené chování při selhání. Spusťte každou kontrolu s jednou cestou zhoršenou a poté s jednou cestou odstraněnou.

Jeden úspěšný přenos souboru přes změnu cesty nedokazuje nepřetržitý provoz. Zopakujte přenos při přepínání preferované cesty a zkontrolujte pohled operátora i vlastní počítadla VPN. Pokud se oba neshodnou, která cesta nesla data, smlouva ještě není pozorovatelná.

Uchovejte schválenou matici s nasazením. Říká dalšímu inženýrovi, jaké chování bylo slíbeno, které kombinace cest se testovaly a který režim selhání zůstává nepodporovaný, bez dalšího kola hádání podle kontrolek stavu propojení.