VPN por varias rutas: catro garantías que debe ofrecer o operador

Engada un segundo enlace WAN e os túneles levantan, pero unha copia de ficheiro aínda se atasca cando unha ruta falla. Os enlaces están sans e os procesos VPN execútanse; o que falta é un contrato entre o operador e o túnel. Varios sockets non se comportan automaticamente como unha soa conexión, e a aplicación que está por riba non nota a diferenza ata que a entrega rompe. Cada parte do contrato corresponde a un fallo que pode probar, e iso é o que o fai útil.

Escriba ese contrato antes de escoller un produto. Ten catro partes: o fluxo que recibe a VPN, como recupera o operador os datos perdidos, que identidade de extremo sobrevive a un cambio de ruta e como se comporta todo cando unha ruta falla.

O síntoma: os enlaces están activos, a sesión segue rompendo

Un gráfico de monitorización que mostra ambos os enlaces activos só demostra que cada ruta pode transportar tráfico. Non demostra que a VPN vexa un único fluxo ordenado, que un paquete perdido nunha ruta se recupere noutra, nin que o par siga sabendo con que sesión fala. O resto do contrato cobre o que ese gráfico non pode mostrar.

Cando unha transferencia se atasca, averigüe se o operador seguiu entregando pola ruta supervivente. Se a sesión morre mentres o segundo enlace está inactivo, o operador nunca o usou. Se a sesión sobrevive pero os datos chegan desordenados ou duplicados, o operador move paquetes sen un contrato de nivel de conexión. As marcas de tempo en ambos os lados adoitan deixalo claro.

Esa distinción decide a solución. Un problema de encamiñamento ou de política necesita un cambio de selección de ruta; unha capa de ordenación e recuperación ausente necesita outro transporte, non un búfer maior.

Garantía un: un fluxo de bytes a nivel de conexión

Se a VPN necesita un fluxo ordenado e fiable, o operador debe identificar rangos de bytes por riba da ruta individual. Cada conexión TCP subxacente só numera os seus propios segmentos, así que un receptor non pode reordenar entre rutas usando só eses números.

Multipath TCP é o exemplo estandarizado. Presenta un fluxo de bytes fiable mentres coordina varios subfluxos TCP, con mapeo de secuencia e acuse de recibo a nivel de datos. A aplicación le un fluxo, non o subfluxo que entregou un fragmento primeiro.

En Linux, MPTCP actívase por socket mediante IPPROTO_MPTCP. Cando a negociación non pode usar comportamento multipath, o retroceso documentado é TCP normal, o que significa que a aplicación pode seguir funcionando por unha ruta sen usar nunca a segunda. Comprobe que comportamento negociou realmente o socket despregado en lugar de supoñer que se aplicou a configuración do núcleo.

Garantía dous: ordenación, duplicación e recuperación

As rutas con retardos e taxas de perda distintos obrigan o operador a almacenar, reordenar e retransmitir. O contrato debe indicar canto almacenamento se permite, que contrapresión ve a aplicación e que ruta transporta unha retransmisión.

Unha ruta que segue conectada pero deixa de entregar é máis difícil que un peche limpo. O operador debe detectala, mover os datos pendentes e evitar esperar para sempre un segmento que nunca chegará. Unha comprobación simple de que ambos os enlaces están activos non cobre este estado.

A duplicación necesita a súa propia regra. Enviar a mesma carga por ambas as rutas pode mellorar a latencia, pero o receptor debe suprimir a copia antes de que chegue á VPN. A protección anti-replay de IPsec é opcional por asociación de seguridade e comproba os números de secuencia; unha capa de duplicación que reordena ou repite paquetes pode activala ou ocultar o problema ata que o túnel caia.

Garantía tres: identidade de extremo e unión de rutas

O par necesita unha forma estable de recoñecer a sesión cando aparece unha ruta nova. Se cada ruta se autentica como un túnel separado, a VPN pode ver dúas sesións en lugar de unha. Se o operador une rutas baixo unha sesión, debe definir como se autentica a nova e que ocorre coa antiga.

Anote que enderezos e identificadores permanecen estables: o extremo do túnel, o identificador de sesión do operador e calquera proxy intermedio. Un proxy engade outra fronteira de dispoñibilidade e confianza aínda que nunca vexa a carga protexida.

Aquí tamén reside a política. Unha ruta que se une desde unha rede inesperada pode ser tecnicamente válida e aínda así violar o modelo de confianza previsto. Decida se as rutas novas se aceptan automaticamente, esixen autenticación ou se rexeitan.

Garantía catro: comportamento acoutado ante fallos

Probe un fallo completo de ruta, non só unha ruta lenta. A ruta supervivente debería transportar a sesión sen un crecemento ilimitado de memoria, e a recuperación non debería depender dun temporizador máis longo do que a aplicación pode tolerar. Cando volve a ruta fallida, o operador debe decidir se reequilibra ou deixa o fluxo onde está.

Fixe límites de almacenamento, retransmisión e número de rutas, e verifíqueos con perda, reordenación, duplicación e desequilibrio de retardo. O ancho de banda agregado é o número menos interesante aquí; a continuidade de entrega e os límites de memoria son o contrato.

Manteña o estado de recuperación do operador separado do estado criptográfico da VPN. Unha capa de fiabilidade propia que substitúa a autenticación ou o cifrado establecidos non é un atallo, e reutilizar números de secuencia entre capas fai que a protección contra repeticións e o diagnóstico deixen de ser fiables.

Acepte o operador cun plan de probas

Escriba as catro garantías como comprobacións de pasa ou falla: un fluxo ordenado, recuperación definida, identidade de sesión estable e comportamento de fallo acoutado. Execute cada comprobación cunha ruta degradada e despois cunha ruta eliminada.

Unha única transferencia de ficheiro correcta a través dun cambio de ruta non demostra un funcionamento continuo. Repita a transferencia mentres alterna a ruta preferida e inspeccione tanto a visión do operador como os contadores propios da VPN. Se os dous non coinciden sobre que ruta transportou os datos, o contrato aínda non é observable.

Garde a matriz aprobada co despregamento. Indica ao seguinte enxeñeiro que comportamento se prometeu, que combinacións de rutas se probaron e que modo de fallo segue sen soporte, sen outra rolda de conxecturas a partir das luces de estado dos enlaces.