VPN yfir margar slóðir: fjórar tryggingar sem flutningsaðilinn verður að veita

Bættu við annarri WAN-tengingu og göngin koma upp, en afritun skráar stöðvast samt þegar ein slóð skikar. Tengingarnar eru heilbrigðar og VPN-ferlarnir keyra; það sem vantar er samningur milli flutningsaðilans og gangsins. Nokkrir sokkar hegða sér ekki sjálfkrafa eins og ein tenging, og forritið fyrir ofan þá getur ekki greint muninn fyrr en afhendingin brestur. Hver hluti samningsins samsvarar bilun sem þú getur prófað, og það gerir hann gagnlegan.

Skrifaðu þann samning áður en þú velur vöru. Hann hefur fjóra hluta: strauminn sem VPN-ið tekur við, hvernig flutningsaðilinn endurheimtir týnd gögn, hvaða auðkenni endapunkts lifir slóðabreytingu af, og hvernig heildin hegðar sér þegar slóð brestur.

Einkennið: tengingarnar eru uppi, setan brestur samt

Vöktunargraf sem sýnir báðar tengingar uppi sannar aðeins að hver slóð geti borið umferð. Það sannar ekki að VPN-ið sjái einn raðaðan straum, að pakki sem týndist á einni slóð sé endurheimtur á annarri, né að jafninginn viti enn hvaða setu hann talar við. Restin af samningnum nær yfir það sem grafið getur ekki sýnt.

Þegar flutningur stöðvast skaltu komast að því hvort flutningsaðilinn hélt áfram að afhenda á slóðinni sem lifir. Ef setan deyr meðan önnur tengingin er aðgerðalaus notaði flutningsaðilinn hana aldrei. Ef setan lifir en gögn koma óröðuð eða tvítekin færir flutningsaðilinn pakka án samnings á tengingarstigi. Tímastimplar á báðum hliðum gera það yfirleitt ljóst.

Sá munur ræður lagfæringunni. Leiðarvandamál eða stefnumál þarf að breyta slóðavali; vantar lag fyrir röðun og endurheimt þarf annan flutning, ekki stærri biðminni.

Trygging eitt: bytestraumur á tengingarstigi

Ef VPN-ið þarf áreiðanlegan raðaðan straum verður flutningsaðilinn að auðkenna bætasvið ofan við einstöku slóðina. Hver undirliggjandi TCP-tenging númerar aðeins eigin hluta, svo viðtakandi getur ekki raðað aftur milli slóða með þeim númerum einum saman.

Multipath TCP er staðlaða dæmið. Það býður einn áreiðanlegan bytestraum á meðan það samhæfir nokkra TCP-undirstrauma, með röðunarkortlagningu og staðfestingu á gagnastigi. Forritið les straum, ekki undirstrauminn sem afhenti bút fyrst.

Á Linux er MPTCP valkvætt fyrir hvern sokk gegnum IPPROTO_MPTCP. Þegar samningaviðræðurnar geta ekki notað fjölslóðahegðun er skjalfesta afturhvarfið venjulegt TCP, sem þýðir að forritið gæti haldið áfram á einni slóð án þess að nota hina nokkurn tíma. Athugaðu hvaða hegðun sokkinn sem var virkjaður samdi í raun um í stað þess að gera ráð fyrir að kjarnastillingin hafi gilt.

Trygging tvö: röðun, tvítekning og endurheimt

Slóðir með mismunandi töfum og tapstöðum neyða flutningsaðilann til að biðminnisfylla, raða aftur og endursenda. Samningurinn verður að taka fram hversu mikil biðminnisfylling er leyfileg, hvaða bakþrýsting forritið sér og hvaða slóð ber endursendingu.

Slóð sem helst tengd en hættir að afhenda er erfiðari en hrein lokun. Flutningsaðilinn verður að greina hana, færa útistandandi gögn og forðast að bíða eilíft eftir hluta sem kemur aldrei. Einföld athugun á því að báðar tengingar séu uppi nær ekki yfir þetta ástand.

Tvítekning þarf sína eigin reglu. Að senda sama farm á báðum slóðum getur bætt töf, en viðtakandinn verður að bæla afritið áður en það nær VPN-inu. IPsec-anti-replay er valfrjálst fyrir hverja öryggissamtengingu og athugar raðnúmer; tvítekningarlag sem raðar aftur eða endurspilar pökkum getur virkjað það eða falið vandamálið þar til gangurinn fellur.

Trygging þrjú: auðkenni endapunkts og slóðartenging

Jafninginn þarf áreiðanlega leið til að þekkja setuna þegar ný slóð birtist. Ef hver slóð er auðkennd sem sér gangur gæti VPN-ið séð tvær setur í stað einnar. Ef flutningsaðilinn tengir slóðir undir einni setu verður hann að skilgreina hvernig nýja slóðin er auðkennd og hvað verður um þá gömlu.

Skráðu hvaða vistföng og auðkenni haldast stöðug: endapunktur gangsins, setuauðkenni flutningsaðilans og hvaða milliþjónn sem er á milli. Milliþjónn bætir við annarri framboðs- og traustmörkum jafnvel þótt hann sjái aldrei varðaða farminn.

Hér býr líka stefnan. Slóð sem tengist frá óvæntu neti getur verið tæknilega gild og samt brotið fyrirhugað traustmódel. Ákveddu hvort nýjar slóðir eru samþykktar sjálfkrafa, krefjast auðkenningar eða eru hafnað.

Trygging fjögur: takmörkuð hegðun við bilun

Prófaðu algjöra bilun slóðar, ekki bara hæga slóð. Slóðin sem lifir ætti að bera setuna án ótakmarkaðs minnisvaxtar, og endurheimt ætti ekki að ráðast af tímastilli sem er lengri en forritið þolir. Þegar bilaða slóðin kemur aftur verður flutningsaðilinn að ákveða hvort hann endurjafni eða láti flæðið vera þar sem það er.

Setjið mörk fyrir biðminnisfyllingu, endursendingu og fjölda slóða, og sannreynið þau undir tapi, endurröðun, tvítekningu og tafarójafnvægi. Samanlagt bandvídd er minna áhugaverða talan hér; samfelld afhending og minnismörk eru samningurinn.

Hafið endurheimtarástand flutningsaðilans aðskilið frá dulritunarástandi VPN-sins. Sérsniðið áreiðanleikarlag sem kemur í stað staðfestrar auðkenningar eða dulritunar er engin flýtileið, og endurnotkun raðnúmera milli laga gerir endurspilunarvörn og greiningu óáreiðanlega.

Samþykktu flutningsaðilann með prófunaráætlun

Skrifaðu fjórar tryggingarnar sem staðist- eða-fallist-próf: einn raðaður straumur, skilgreind endurheimt, stöðugt setuauðkenni, takmörkuð bilunarhegðun. Keyrðu hvert próf með eina slóð skerta og síðan með eina slóð fjarlægða.

Einn árangursríkur skráarflutningur í gegnum slóðabreytingu sannar ekki samfellda starfsemi. Endurtaktu flutninginn á meðan þú skiptir um valda slóð, og skoðaðu bæði sýn flutningsaðilans og eigin teljara VPN-sins. Ef þeir eru ósammála um hvaða slóð bar gögnin er samningurinn enn ekki sjáanlegur.

Varðveittu samþykktu fylkið með uppsetningunni. Það segir næsta verkfræðingi hvaða hegðun var lofað, hvaða slóðasamsetningar voru prófaðar og hvaða bilunarhamur er enn óstuddur, án annarrar umferðar giskana út frá stöðuljósum tenginganna.