VPN sur pluraj vojoj: kvar garantioj, kiujn la operatoro devas provizi

Aldonu duan WAN-ligilon kaj la tuneloj leviĝas, sed dosiera kopio ankoraŭ haltas kiam unu vojo ŝanceliĝas. La ligiloj sanas kaj la VPN-procesoj funkcias; mankas kontrakto inter la operatoro kaj la tunelo. Pluraj ingoj ne aŭtomate kondutas kiel unu konekto, kaj la aplikaĵo super ili ne povas vidi la diferencon ĝis la liverado rompiĝas. Ĉiu parto de la kontrakto respondas al fiasko, kiun vi povas testi, kaj tio estas kio igas ĝin utila.

Skribu tiun kontrakton antaŭ ol elekti produkton. Ĝi havas kvar partojn: la fluo, kiun la VPN ricevas, kiel la operatoro restaŭras mankantajn datumojn, kiu finpunkta identeco postvivas vojoŝanĝon, kaj kiel la tuto kondutas kiam vojo fiaskas.

La simptomo: ligiloj supren, la sesio tamen rompiĝas

Monitora grafo montranta ambaŭ ligilojn supren pruvas nur ke ĉiu vojo povas porti trafikon. Ĝi ne pruvas, ke la VPN vidas unu ordigitan fluon, ke paketo perdita sur unu vojo restaŭriĝas sur alia, aŭ ke la samtavolano ankoraŭ scias kun kiu sesio ĝi parolas. La resto de la kontrakto kovras tion, kion la grafo ne povas montri.

Kiam transigo haltas, eltrovu ĉu la operatoro daŭrigis liveradon sur la postvivinta vojo. Se la sesio mortas dum la dua ligilo estas senokupa, la operatoro neniam uzis ĝin. Se la sesio postvivas sed datumoj alvenas eksterorde aŭ duobligitaj, la operatoro movas paketojn sen konekta-nivela kontrakto. Tempomarkoj ambaŭflanke kutime klarigas tion.

Tiu diferenco decidas la riparon. Enkursiga aŭ politika problemo bezonas ŝanĝon de voja elekto; mankanta ordo- kaj restaŭra tavolo bezonas alian transporton, ne pli grandan bufron.

Unua garantio: bajta fluo je konekta nivelo

Se la VPN bezonas fidindan ordigitan fluon, la operatoro devas identigi bajtajn intervalojn super la unuopa vojo. Ĉiu suba TCP-konekto numeras nur siajn proprajn segmentojn, do ricevanto ne povas reordigi inter vojoj per nur tiuj numeroj.

Multipath TCP estas la normigita ekzemplo. Ĝi prezentas unu fidindan bajtan fluon dum ĝi kunordigas plurajn TCP-subfluojn, kun datumnivela sekvenca mapado kaj konfirmo. La aplikaĵo legas fluon, ne la subfluon, kiu hazarde liveris pecon unue.

En Linux, MPTCP estas opt-in por ĉiu ingo per IPPROTO_MPTCP. Kiam la intertraktado ne povas uzi plurmovan konduton, la dokumentita replikaĵo estas ordinara TCP, kio signifas, ke la aplikaĵo povas daŭrigi sur unu vojo sen iam uzi la duan. Kontrolu, kiun konduton la deplojita ingo efektive intertraktis, anstataŭ supozi ke la kernagordo validas.

Dua garantio: ordo, duobligo kaj restaŭro

Vojoj kun diversaj prokrastoj kaj perderoj devigas la operatoron bufri, reordigi kaj resendi. La kontrakto devas deklari, kiom da bufrado estas permesata, kiun kontraŭpremon la aplikaĵo vidas, kaj kiun vojon portas resendo.

Vojo, kiu restas konektita sed ĉesas liveri, estas pli malfacila ol pura fermo. La operatoro devas ĝin detekti, movi restantajn datumojn kaj eviti senfinan atenton al segmento, kiu neniam alvenos. Simpla kontrolo, ke ambaŭ ligiloj estas supren, ne kovras ĉi tiun staton.

Duobligo bezonas sian propran regulon. Sendi la saman ŝarĝon sur ambaŭ vojoj povas plibonigi latenton, sed la ricevanto devas subpremi la kopion antaŭ ol ĝi atingos la VPN. IPsec anti-replay estas laŭvola por ĉiu sekureca asocio kaj kontrolas sekvencnumerojn; duobliga tavolo, kiu reordigas aŭ reludas paketojn, povas ŝpari ĝin aŭ kaŝi la problemon ĝis la tunelo falos.

Tria garantio: finpunkta identeco kaj voja aliĝo

La samtavolano bezonas stabilan manieron rekoni la sesion kiam nova vojo aperas. Se ĉiu vojo aŭtentikiĝas kiel aparta tunelo, la VPN povas vidi du sesiojn anstataŭ unu. Se la operatoro kunigas vojojn sub unu sesio, ĝi devas difini, kiel la nova vojo aŭtentikiĝas kaj kio okazas al la malnova.

Notu, kiuj adresoj kaj identigiloj restas stabilaj: la tunela finpunkto, la sesia identigilo de la operatoro kaj ajna prokurilo inter ili. Prokurilo aldonas plian haveblecan kaj fidan limon eĉ kiam ĝi neniam vidas la protektitan ŝarĝon.

Ĉi tie ankaŭ loĝas la politiko. Vojo aliĝanta el neatendita reto povas esti teknike valida kaj tamen malobservi la celitan fidan modelon. Decidu, ĉu novaj vojoj estas akceptataj aŭtomate, postulas aŭtentikigon aŭ estas rifuzataj.

Kvara garantio: limigita konduto sub fiasko

Testu plenan vojfiaskon, ne nur malrapidan vojon. La postvivinta vojo devus porti la sesion sen senlima memorkresko, kaj restaŭro ne devus dependi de tempigilo pli longa ol la aplikaĵo toleras. Kiam la fiaskinta vojo revenas, la operatoro devas decidi ĉu reekvilibrigi aŭ lasi la fluon kie ĝi estas.

Fiksu limojn por bufrado, resendo kaj voja nombro, poste kontrolu ilin sub perdo, reordigo, duobligo kaj prokrasta malekvilibro. Agregata bendolarĝo estas la malplej interesa nombro ĉi tie; liverada kontinueco kaj memorklimoj estas la kontrakto.

Tenu la restaŭran staton de la operatoro aparte de la kriptografia stato de la VPN. Propra fidindeca tavolo, kiu anstataŭas establitan aŭtentikigon aŭ ĉifradon, ne estas fuŝvojo, kaj reuzi sekvencnumerojn inter tavoloj igas replay-protektadon kaj diagnozadon nefidindaj.

Akceptu la operatoron per testplano

Skribu la kvar garantiojn kiel pasintaj-aŭ-fiaskintaj kontroloj: unu ordigita fluo, difinita restaŭro, stabila sesia identeco, limigita fiaskokonduto. Rulu ĉiun kontrolon kun unu vojo degradita kaj poste kun unu vojo forigita.

Unu sukcesa dosiera transigo tra voja ŝanĝo ne pruvas daŭran funkciadon. Ripetu la transigon dum vi ŝaltas la preferatan vojon, kaj inspektu kaj la vidon de la operatoro kaj la proprajn nombrilojn de la VPN. Se la du malkonsentas pri tio, kiun vojon portis la datumojn, la kontrakto ankoraŭ ne estas observebla.

Konservu la subskribitan matricon kun la deplojo. Ĝi diras al la sekva inĝeniero, kiu konduto estis promesita, kiuj vojaj kombinaĵoj estis testitaj kaj kiu fiaskoreĝimo ankoraŭ ne estas subtenata, sen plia raŭndo da konjektado laŭ ligilaj statlumoj.