Lisage teine WAN-link ja tunnelid tõusevad, kuid faili kopeerimine takerdub endiselt, kui üks tee kõigub. Lingid on terved ja VPN-protsessid töötavad; puudu on leping operaatori ja tunneli vahel. Mitu socketit ei käitu automaatselt nagu üks ühendus, ja nende kohal olev rakendus ei näe erinevust enne, kui tarnimine katkeb. Leping iga osa vastab tõrkele, mida saate testida, ja just see teeb selle kasulikuks.

Kirjutage see leping enne toote valimist. Sellel on neli osa: voog, mille VPN vastu võtab, kuidas operaator puuduvaid andmeid taastab, milline lõpp-punkti identiteet jääb tee muutumisel püsima ja kuidas kogu süsteem käitub, kui tee ebaõnnestub.

Sümptom: lingid on üleval, sessioon katkeb ikkagi

Jälgimisgraafik, mis näitab mõlemat linki üleval, tõestab ainult seda, et iga tee suudab liiklust kanda. See ei tõesta, et VPN näeb üht järjestatud voogu, et ühel teel kaotatud pakett taastatakse teisel, ega seda, et partner teab endiselt, millise sessiooniga ta räägib. Ülejäänud leping katab selle, mida graafik näidata ei suuda.

Kui ülekanne takerdub, tehke kindlaks, kas operaator jätkas tarnimist ellujäänud teel. Kui sessioon sureb, kui teine link on jõude, ei kasutanud operaator seda kunagi. Kui sessioon jääb püsima, kuid andmed saabuvad vales järjekorras või dubleeritult, liigutab operaator pakette ilma ühendustasandi lepinguta. Aegtemplid mõlemal pool teevad selle tavaliselt selgeks.

See erinevus otsustab paranduse. Marsruutimis- või poliitikaprobleem nõuab teevaliku muutmist; puuduv järjestus- ja taastamiskihT nõuab teist transporti, mitte suuremat puhvrit.

Tagatis üks: baidivoog ühendustasandil

Kui VPN vajab usaldusväärset järjestatud voogu, peab operaator tuvastama baidivahemikud üksiku tee kohal. Iga aluseks olev TCP-ühendus nummerdab ainult oma segmente, seega ei saa vastuvõtja üksnes nende numbritega teede vahel ümber järjestada.

Multipath TCP on standardiseeritud näide. See esitab ühe usaldusväärse baidivoo, koordineerides samal ajal mitut TCP-alavoolu, andmetasandi järjestuskaardistuse ja kinnitusega. Rakendus loeb voogu, mitte alavoolu, mis juhtus tüki esimesena tarnima.

Linuxis on MPTCP iga socketi puhul opt-in IPPROTO_MPTCP kaudu. Kui läbirääkimine ei saa mitmetee-käitumist kasutada, on dokumenteeritud tagavaravariant tavaline TCP, mis tähendab, et rakendus võib jätkata ühel teel, kasutamata kunagi teist. Kontrollige, millise käitumise kasutusele võetud socket tegelikult läbi rääkis, selle asemel et eeldada kerneli seade rakendumist.

Tagatis kaks: järjestus, dubleerimine ja taastamine

Erinevate viivituste ja kadudega teed sunnivad operaatorit puhverdama, ümber järjestama ja uuesti saatma. Leping peab sätestama, kui palju puhverdust lubatakse, millist vastusurvet rakendus näeb ja milline tee kannab kordussaatmist.

Tee, mis jääb ühendatuks, kuid lakkab tarnimast, on raskem kui puhas sulgemine. Operaator peab selle tuvastama, ootel andmeid liigutama ja vältima igavest ootamist segmenti, mis kunagi ei saabu. Lihtne kontroll, et mõlemad lingid on üleval, ei kata seda olekut.

Dubleerimine vajab oma reeglit. Sama kandevõime saatmine mõlemal teel võib latentsust parandada, kuid vastuvõtja peab koopia maha suruma enne, kui see VPN-ini jõuab. IPsec anti-replay on iga turvaassotsiatsiooni puhul valikuline ja kontrollib järjekorranumbreid; dubleerimiskiht, mis järjestab ümber või kordab pakette, võib selle käivitada või probleemi peita, kuni tunnel langeb.

Tagatis kolm: lõpp-punkti identiteet ja tee liitumine

Partner vajab stabiilset viisi sessiooni äratundmiseks, kui ilmub uus tee. Kui iga tee autenditakse eraldi tunnelina, võib VPN näha kahte sessiooni ühe asemel. Kui operaator ühendab teed ühe sessiooni alla, peab ta määratlema, kuidas uus tee autenditakse ja mis juhtub vanaga.

Kirjutage üles, millised aadressid ja identifikaatorid jäävad stabiilseks: tunneli lõpp-punkt, operaatori sessiooniidentifikaator ja mis tahes vahendaja. Vahendaja lisab veel ühe kättesaadavuse ja usalduse piiri isegi siis, kui ta ei näe kunagi kaitstud kandevõimet.

Siin elab ka poliitika. Ootamatust võrgust liituv tee võib olla tehniliselt kehtiv ja siiski rikkuda kavandatud usaldusmudelit. Otsustage, kas uued teed võetakse automaatselt vastu, nõuavad autentimist või lükatakse tagasi.

Tagatis neli: piiratud käitumine tõrke korral

Testige täielikku tee tõrget, mitte ainult aeglast teed. Ellujäänud tee peaks sessiooni kandma piiramatu mälukasvuta ja taastamine ei tohiks sõltuda taimerist, mis on pikem, kui rakendus talub. Kui ebaõnnestunud tee naaseb, peab operaator otsustama, kas tasakaalustada uuesti või jätta voog paigale.

Seadke puhverdamise, kordussaatmise ja teede arvu piirid ning kontrollige neid kadude, ümberjärjestamise, dubleerimise ja viivituse tasakaalustamatuse korral. Liidetud ribalaius on siin kõige vähem huvitav arv; tarnimise järjepidevus ja mälupiirid on leping.

Hoidke operaatori taastamiseisund VPN-i krüptograafilisest seisundist eraldi. Kohandatud usaldusväärsuse kiht, mis asendab kehtestatud autentimise või krüpteerimise, ei ole lühike tee, ja järjekorranumbrite korduskasutamine kihtide vahel muudab replay-kaitse ja diagnostika ebausaldusväärseks.

Võtke operaator vastu testplaaniga

Kirjutage neli tagatist läbitud-või-ebaõnnestunud kontrollidena: üks järjestatud voog, määratletud taastamine, stabiilne sessiooniidentiteet, piiratud tõrkekäitumine. Käivitage iga kontroll ühe teega halvendatuna ja seejärel ühe teega eemaldatuna.

Üks edukas failiülekanne tee muutmise ajal ei tõesta pidevat tööd. Korrake ülekannet, vahetades eelistatud teed, ja uurige nii operaatori vaadet kui ka VPN-i enda loendureid. Kui need kaks ei ole ühel meelel, milline tee andmeid kandis, ei ole leping veel vaadeldav.

Hoidke kinnitatud maatriksit juurutuse juures. See ütleb järgmisele insenerile, milline käitumine lubati, milliseid teekombinatsioone testiti ja milline tõrkerežiim on endiselt toetamata, ilma uue oletuste vooruta lingi oleku tuledest.

Seotud artiklid