VPN per diversos camins: quatre garanties que ha de proporcionar l’operador

Afegiu un segon enllaç WAN i els túnels s’aixequen, però una còpia de fitxer encara s’atura quan un camí trontolla. Els enllaços són sans i els processos VPN s’executen; el que falta és un contracte entre l’operador i el túnel. Diversos sockets no es comporten automàticament com una sola connexió, i l’aplicació que hi ha a sobre no pot notar la diferència fins que el lliurament es trenca. Cada part del contracte correspon a una fallada que podeu provar, i això és el que el fa útil.

Escriviu aquest contracte abans de triar un producte. Té quatre parts: el flux que rep la VPN, com recupera l’operador les dades que falten, quina identitat de punt final sobreviu a un canvi de camí i com es comporta tot plegat quan un camí falla.

El símptoma: els enllaços estan actius, la sessió encara es trenca

Un gràfic de monitoratge que mostra els dos enllaços actius només demostra que cada camí pot transportar trànsit. No demostra que la VPN vegi un sol flux ordenat, que un paquet perdut en un camí es recuperi en un altre, ni que el parell encara sàpiga amb quina sessió parla. La resta del contracte cobreix el que aquest gràfic no pot mostrar.

Quan una transferència s’atura, esbrineu si l’operador va continuar lliurant pel camí supervivent. Si la sessió mor mentre el segon enllaç està inactiu, l’operador no l’ha fet servir mai. Si la sessió sobreviu però les dades arriben desordenades o duplicades, l’operador mou paquets sense un contracte de nivell de connexió. Les marques de temps a banda i banda normalment ho deixen clar.

Aquesta distinció decideix la solució. Un problema d’encaminament o de política necessita un canvi de selecció de camí; una capa d’ordenació i recuperació absent necessita un transport diferent, no un buffer més gran.

Garantia u: un flux de bytes a nivell de connexió

Si la VPN necessita un flux ordenat i fiable, l’operador ha d’identificar intervals de bytes per damunt del camí individual. Cada connexió TCP subjacent només numera els seus propis segments, de manera que un receptor no pot reordenar entre camins fent servir només aquests números.

Multipath TCP és l’exemple estandarditzat. Presenta un flux de bytes fiable mentre coordina diversos subfluxos TCP, amb mapatge de seqüència i confirmació a nivell de dades. L’aplicació llegeix un flux, no el subflux que va lliurar una peça primer.

A Linux, MPTCP s’activa per socket mitjançant IPPROTO_MPTCP. Quan la negociació no pot fer servir el comportament multipath, el retrocés documentat és TCP ordinari, cosa que significa que l’aplicació pot continuar funcionant per un camí sense arribar a utilitzar mai el segon. Comproveu quin comportament ha negociat realment el socket desplegat en lloc de suposar que s’ha aplicat la configuració del nucli.

Garantia dos: ordenació, duplicació i recuperació

Els camins amb retards i taxes de pèrdua diferents obliguen l’operador a emmagatzemar, reordenar i retransmetre. El contracte ha d’indicar quant emmagatzematge es permet, quina pressió inversa veu l’aplicació i quin camí transporta una retransmissió.

Un camí que continua connectat però deixa de lliurar és més difícil que un tancament net. L’operador ha de detectar-lo, moure les dades pendents i evitar esperar per sempre un segment que no arribarà mai. Una comprovació simple que els dos enllaços estan actius no cobreix aquest estat.

La duplicació necessita una regla pròpia. Enviar la mateixa càrrega pels dos camins pot millorar la latència, però el receptor ha de suprimir la còpia abans que arribi a la VPN. L’anti-replay d’IPsec és opcional per associació de seguretat i comprova els números de seqüència; una capa de duplicació que reordena o repeteix paquets pot activar-lo o amagar el problema fins que el túnel cau.

Garantia tres: identitat de punt final i unió de camins

El parell necessita una manera estable de reconèixer la sessió quan apareix un camí nou. Si cada camí s’autentica com un túnel separat, la VPN pot veure dues sessions en lloc d’una. Si l’operador uneix camins sota una sessió, ha de definir com s’autentica el camí nou i què passa amb el vell.

Registreu quines adreces i identificadors romanen estables: el punt final del túnel, l’identificador de sessió de l’operador i qualsevol intermediari. Un intermediari afegeix una altra frontera de disponibilitat i confiança fins i tot quan mai no veu la càrrega protegida.

Aquí també hi viu la política. Un camí que s’uneix des d’una xarxa inesperada pot ser tècnicament vàlid i tot i així violar el model de confiança previst. Decidiu si els camins nous s’accepten automàticament, requereixen autenticació o es rebutgen.

Garantia quatre: comportament acotat davant de fallades

Proveu una fallada completa de camí, no només un camí lent. El camí supervivent hauria de portar la sessió sense un creixement il·limitat de memòria, i la recuperació no hauria de dependre d’un temporitzador més llarg del que l’aplicació pot tolerar. Quan el camí fallit torna, l’operador ha de decidir si reequilibra o deixa el flux on és.

Fixeu límits per a l’emmagatzematge, la retransmissió i el nombre de camins, i verifiqueu-los amb pèrdua, reordenació, duplicació i desequilibri de retard. L’amplada de banda agregada és el número menys interessant aquí; la continuïtat de lliurament i els límits de memòria són el contracte.

Mantingueu l’estat de recuperació de l’operador separat de l’estat criptogràfic de la VPN. Una capa de fiabilitat pròpia que substitueix l’autenticació o el xifratge establerts no és cap drecera, i reutilitzar números de seqüència entre capes és com la protecció contra repeticions i el diagnòstic es tornen poc fiables.

Accepteu l’operador amb un pla de proves

Escriviu les quatre garanties com a comprovacions de passa o falla: un flux ordenat, recuperació definida, identitat de sessió estable i comportament de fallada acotat. Executeu cada comprovació amb un camí degradat i després amb un camí eliminat.

Una única transferència de fitxer reeixida a través d’un canvi de camí no demostra un funcionament continu. Repetiu la transferència mentre canvieu el camí preferit i inspeccioneu tant la visió de l’operador com els comptadors propis de la VPN. Si els dos no coincideixen sobre quin camí va portar les dades, el contracte encara no és observable.

Conserveu la matriu aprovada amb el desplegament. Indica al següent enginyer quin comportament es va prometre, quines combinacions de camins es van provar i quin mode de fallada continua sense suport, sense una altra ronda d’endevinar a partir dels llums d’estat dels enllaços.