VPN over fleire baner: fire garantiar som transportøren må levere

Legg til ei ekstra WAN-lenkje, og tunnelane kjem opp, men ein filkopi stoppar framleis når éi bane vinglar. Lenkjene er friske og VPN-prosessane køyrer; det som manglar, er ein kontrakt mellom transportøren og tunnelen. Fleire sockets oppfører seg ikkje automatisk som éi tilkopling, og applikasjonen over dei ser ikkje skilnaden før leveringa bryt saman. Kvar del av kontrakten svarar til ein feil du kan teste, og det er det som gjer han nyttig.

Skriv den kontrakten før du vel eit produkt. Han har fire delar: straumen VPN-en tek imot, korleis transportøren gjenopprettar manglande data, kva endepunktidentitet som overlever eit banebytte, og korleis heilskapen oppfører seg når ei bane feilar.

Symptomet: lenkjene er oppe, økta bryt likevel

Ein overvakingsgraf som viser båe lenkjene oppe, beviser berre at kvar bane kan bera trafikk. Han beviser ikkje at VPN-en ser éin ordna straum, at ein pakke som gjekk tapt på éi bane blir gjenoppretta på ei anna, eller at motparten framleis veit kva økt han snakkar med. Resten av kontrakten dekkjer det grafen ikkje kan vise.

Når ein overføring stoppar, finn ut om transportøren heldt fram med å levere på bana som overlevde. Døyr økta medan den andre lenkja er ledig, har transportøren aldri brukt henne. Overlever økta, men data kjem i feil rekkjefølgje eller duplisert, flyttar transportøren pakkar utan ein kontrakt på tilkopingsnivå. Tidsstempel på båe sider gjer det vanlegvis klart.

Den skilnaden avgjer løysinga. Eit ruting- eller policyproblem krev eit anna baneval; eit manglande lag for rekkjefølgje og gjenoppretting krev ein annan transport, ikkje ein større buffer.

Garanti éin: ein bytestraum på tilkopingsnivå

Viss VPN-en treng ein påliteleg ordna straum, må transportøren identifisere byteområde over den enkelte bana. Kvar underliggjande TCP-tilkopling nummererer berre sine eigne segment, så ein mottakar kan ikkje omorganisere på tvers av baner med berre desse numra.

Multipath TCP er det standardiserte dømet. Det presenterer éin påliteleg bytestraum medan det koordinerer fleire TCP-substraumar, med sekvensmapping og stadfesting på datanivå. Applikasjonen les ein straum, ikkje substrøymen som tilfeldigvis leverte ein bit først.

På Linux er MPTCP opt-in per socket via IPPROTO_MPTCP. Når forhandlinga ikkje kan bruke multipath-åtferd, er den dokumenterte fallbacken vanleg TCP, noko som tyder at applikasjonen kan halde fram over éi bane utan å bruke den andre. Sjekk kva åtferd den utrulla sockelen faktisk forhandla, i staden for å anta at kjerneinnstillinga vart brukt.

Garanti to: rekkjefølgje, duplisering og gjenoppretting

Baner med ulike forseinkingar og taptal tvingar transportøren til å bufre, omorganisere og sende på nytt. Kontrakten må seie kor mykje buftring som er tillaten, kva mottrykk applikasjonen ser, og kva bane som ber ein gjenutsending.

Ei bane som blir verande tilkopla men sluttar å levere, er vanskelegare enn ei rein lukking. Transportøren må oppdage henne, flytte uteståande data og unngå å vente evig på eit segment som aldri kjem. Ein enkel sjekk av at båe lenkjene er oppe, dekkjer ikkje denne tilstanden.

Duplisering treng si eiga regle. Å sende same nyttelast på båe baner kan betre latenstida, men mottakaren må undertrykkje kopien før han når VPN-en. IPsec-anti-replay er valfritt per tryggingsassosiasjon og kontrollerer sekvensnummer; eit dupliseringslag som omorganiserer eller spelar av pakkar på nytt, kan utløyse det eller skjule problemet til tunnelen fell.

Garanti tre: endepunktidentitet og banetilkopling

Motparten treng ein stabil måte å kjenne att økta på når ei ny bane dukkar opp. Viss kvar bane blir autentisert som ein eigen tunnel, kan VPN-en sjå to økter i staden for éi. Viss transportøren sameinar baner under éi økt, må han definere korleis den nye bana blir autentisert og kva som skjer med den gamle.

Noter kva adresser og identifikatorar som blir verande stabile: tunnelendepunktet, øktidentifikatoren til transportøren og ein eventuell proxy imellom. Ein proxy legg til nok ei tilgjengelegheits- og tillitsgrense sjølv når han aldri ser den verna nyttelasten.

Her bur også policyen. Ei bane som koplar seg til frå eit uventa nettverk, kan vere teknisk gyldig og likevel bryte den tiltenkte tillitsmodellen. Bestem om nye baner blir godtekne automatisk, krev autentisering eller blir avviste.

Garanti fire: avgrensa åtferd ved feil

Test ein fullstendig banefeil, ikkje berre ei treg bane. Bana som overlever, skal bera økta utan ubegrensa minnevekst, og gjenopprettinga skal ikkje avhenge av ein timer som er lengre enn applikasjonen toler. Når den feila bana kjem tilbake, må transportøren avgjere om han skal rebalansere eller la flyten bli der han er.

Set grenser for buftring, gjenutsending og talet på baner, og verifiser dei under tap, omorganisering, duplisering og forseinkingsubalanse. Samla bandbreidd er det minst interessante talet her; leveringskontinuitet og minnegrenser er kontrakten.

Hald gjenopprettingstilstanden til transportøren skild frå den kryptografiske tilstanden til VPN-en. Eit eige pålitelegheitslag som erstattar etablert autentisering eller kryptering er inga snarveg, og gjenbruk av sekvensnummer på tvers av lag gjer replay-vern og diagnostikk upåliteleg.

Godta transportøren med ein testplan

Skriv dei fire garantiar som bestått-eller-feila-kontrollar: éin ordna straum, definert gjenoppretting, stabil øktidentitet, avgrensa feilåtferd. Køyr kvar kontroll med éi bane svekka og deretter med éi bane fjerna.

Éin vellukka filoverføring gjennom eit banebytte beviser ikkje kontinuerleg drift. Gjenta overføringa medan du byter den føretrekte bana, og undersøk både synet til transportøren og eigne teljarar i VPN-en. Viss dei to er usamde om kva bane som bar dataa, er kontrakten enno ikkje observerbar.

Ta vare på den godkjende matrisa saman med utrullinga. Ho fortel neste ingeniør kva åtferd som vart lova, kva banekombinasjonar som vart testa og kva feilmodus som framleis ikkje er støtta, utan nok ein runde med gissing frå lenkjestatuslys.