VPN több útvonalon: négy garancia, amelyet a szolgáltatónak nyújtania kell

Adjon hozzá egy második WAN-linket, és az alagutak feljönnek, de egy fájlmásolás továbbra is elakad, amikor az egyik útvonal ingadozik. A linkek egészségesek, a VPN-folyamatok futnak; ami hiányzik, az a szerződés a szolgáltató és az alagút között. Több socket nem viselkedik automatikusan egyetlen kapcsolatként, és a felettük lévő alkalmazás nem látja a különbséget, amíg a kézbesítés meg nem szakad. A szerződés minden része egy tesztelhető hibához kapcsolódik, és ez teszi hasznossá.

Írja meg ezt a szerződést a termékválasztás előtt. Négy része van: a VPN által fogadott folyam, ahogyan a szolgáltató helyreállítja a hiányzó adatokat, melyik végpont-identitás éli túl az útvonalváltást, és hogyan viselkedik az egész, amikor egy útvonal meghibásodik.

A tünet: a linkek fel vannak, a munkamenet mégis megszakad

Egy megfigyelési grafikon, amely mindkét linket felkapcsoltnak mutatja, csak azt bizonyítja, hogy mindegyik útvonal képes forgalmat szállítani. Nem bizonyítja, hogy a VPN egyetlen rendezett folyamot lát, hogy az egyik útvonalon elveszett csomag a másikon helyreáll, vagy hogy a partner még tudja, melyik munkamenettel beszél. A szerződés többi része azt fedi le, amit a grafikon nem tud megmutatni.

Amikor egy átvitel elakad, derítse ki, folytatta-e a szolgáltató a kézbesítést a túlélő útvonalon. Ha a munkamenet meghal, miközben a második link tétlen, a szolgáltató soha nem használta. Ha a munkamenet túlél, de az adatok sorrenden kívül vagy duplikálva érkeznek, a szolgáltató kapcsolatszintű szerződés nélkül mozgat csomagokat. A két oldal időbélyegei általában tisztázzák ezt.

Ez a különbség dönti el a javítást. Az útválasztási vagy házirend-probléma útvonalválasztás-módosítást igényel; a hiányzó sorrendezési és helyreállítási réteg más szállítást igényel, nem nagyobb puffert.

Egyes garancia: bájtfolyam kapcsolatszinten

Ha a VPN-nek megbízható, rendezett folyamra van szüksége, a szolgáltatónak bájtartományokat kell azonosítania az egyes útvonalak felett. Minden mögöttes TCP-kapcsolat csak a saját szegmenseit számozza, így a fogadó nem tud csak ezekkel a számokkal útvonalak között átrendezni.

A Multipath TCP a szabványos példa. Egyetlen megbízható bájtfolyamot nyújt, miközben több TCP-alflow-t koordinál, adatszintű sorrendleképezéssel és nyugtázással. Az alkalmazás folyamot olvas, nem azt az alflow-t, amelyik véletlenül elsőként szállított egy darabot.

Linuxon az MPTCP socketenként opt-in a IPPROTO_MPTCP használatával. Ha a tárgyalás nem tud többutas viselkedést használni, a dokumentált visszaesés a közönséges TCP, ami azt jelenti, hogy az alkalmazás tovább működhet egy útvonalon anélkül, hogy valaha használná a másodikat. Ellenőrizze, milyen viselkedésről tárgyalt ténylegesen a telepített socket, ahelyett hogy feltételezné a kernelbeállítás érvényesülését.

Kettes garancia: sorrendezés, duplikáció és helyreállítás

A eltérő késleltetésű és veszteségarányú útvonalak pufferelésre, átrendezésre és újraküldésre kényszerítik a szolgáltatót. A szerződésnek rögzítenie kell a megengedett puffert, az alkalmazás által látott ellennyomást és azt, melyik útvonal hordozza az újraküldést.

Az az útvonal, amely kapcsolódva marad, de felhagy a kézbesítéssel, nehezebb, mint egy tiszta lezárás. A szolgáltatónak fel kell ismernie, át kell mozgatnia a függőben lévő adatokat, és el kell kerülnie, hogy örökké várjon egy soha meg nem érkező szegmensre. Az egyszerű ellenőrzés, hogy mindkét link fel van-e kapcsolva, nem fedi le ezt az állapotot.

A duplikációnak saját szabálya van. Ugyanazon hasznos teher küldése mindkét útvonalon javíthatja a késleltetést, de a fogadónak el kell nyomnia a másolatot, mielőtt eléri a VPN-t. Az IPsec anti-replay biztonsági társulásonként opcionális, és ellenőrzi a sorszámokat; egy átrendező vagy újrajátszó duplikációs réteg kiválthatja, vagy elrejtheti a problémát, amíg az alagút le nem esik.

Hármas garancia: végpont-identitás és útvonalcsatlakozás

A partnernek stabil módra van szüksége a munkamenet felismerésére, amikor új útvonal jelenik meg. Ha minden útvonalat külön alagútként hitelesítenek, a VPN két munkamenetet láthat egy helyett. Ha a szolgáltató egy munkamenet alá vonja az útvonalakat, meg kell határoznia, hogyan hitelesítik az új útvonalat, és mi történik a régivel.

Jegyezze fel, mely címek és azonosítók maradnak stabilak: az alagút végpontja, a szolgáltató munkamenet-azonosítója és a közbeeső proxy. A proxy újabb elérhetőségi és bizalmi határt ad hozzá, még akkor is, ha soha nem látja a védett hasznos terhet.

Itt lakik a házirend is. Egy váratlan hálózatból csatlakozó útvonal technikailag érvényes lehet, és mégis megsértheti a szándékolt bizalmi modellt. Döntse el, hogy az új útvonalakat automatikusan elfogadják, hitelesítést igényelnek-e, vagy elutasítják.

Négyes garancia: korlátozott viselkedés hiba esetén

Teljes útvonalhibát teszteljen, ne csak lassú útvonalat. A túlélő útvonalnak korlátlan memórianövekedés nélkül kell vinnie a munkamenetet, és a helyreállítás nem függhet az alkalmazás tűréshatáránál hosszabb időzítőtől. Amikor a hibás útvonal visszatér, a szolgáltatónak el kell döntenie, újraegyensúlyoz-e, vagy hagyja a folyamot a helyén.

Állítson határokat a pufferelésre, újraküldésre és az útvonalak számára, majd ellenőrizze őket veszteség, átrendezés, duplikáció és késleltetési egyensúlytalanság mellett. Az összesített sávszélesség itt a legkevésbé érdekes szám; a kézbesítés folytonossága és a memóriakorlátok a szerződés.

Tartsa a szolgáltató helyreállítási állapotát elkülönítve a VPN kriptográfiai állapotától. A bevett hitelesítést vagy titkosítást helyettesítő egyedi megbízhatósági réteg nem rövidítés, és a sorszámok rétegek közötti újrafelhasználása megbízhatatlanná teszi az újbóli lejátszás elleni védelmet és a diagnosztikát.

Fogadja el a szolgáltatót teszttervvel

Írja le a négy garanciát megfelelt vagy nem felelt ellenőrzésként: egy rendezett folyam, meghatározott helyreállítás, stabil munkamenet-identitás, korlátozott hibaviselkedés. Futtassa az ellenőrzéseket egy útvonal rontásával, majd egy útvonal eltávolításával.

Egyetlen sikeres fájlátvitel egy útvonalváltáson át nem bizonyít folyamatos működést. Ismételje meg az átvitelt a preferált útvonal váltogatása közben, és vizsgálja meg a szolgáltató nézetét és a VPN saját számlálóit is. Ha a kettő nem ért egyet abban, melyik útvonal vitte az adatokat, a szerződés még nem megfigyelhető.

Őrizze meg a jóváhagyott mátrixot a telepítés mellett. Megmondja a következő mérnöknek, milyen viselkedést ígértek, mely útvonal-kombinációkat tesztelték, és melyik hibatípus maradt támogatás nélkül, anélkül hogy a linkállapot-lámpákból újabb találgatási kört kellene indítani.