VPN por múltiplos caminhos: quatro garantias que o operador tem de fornecer

Acrescente uma segunda ligação WAN e os túneis sobem, mas uma cópia de ficheiro continua a bloquear quando um caminho oscila. As ligações estão saudáveis e os processos VPN estão a correr; o que falta é um contrato entre o operador e o túnel. Vários sockets não se comportam automaticamente como uma única ligação, e a aplicação por cima não nota a diferença até a entrega falhar. Cada parte do contrato corresponde a uma falha que pode testar, e é isso que o torna útil.

Escreva esse contrato antes de escolher um produto. Tem quatro partes: o fluxo que a VPN recebe, como o operador recupera os dados em falta, que identidade de endpoint sobrevive a uma mudança de caminho e como tudo se comporta quando um caminho falha.

O sintoma: as ligações estão ativas, a sessão cai na mesma

Um gráfico de monitorização que mostra ambas as ligações ativas prova apenas que cada caminho pode transportar tráfego. Não prova que a VPN vê um único fluxo ordenado, que um pacote perdido num caminho é recuperado noutro, nem que o par ainda sabe com que sessão está a falar. O resto do contrato cobre o que esse gráfico não consegue mostrar.

Quando uma transferência bloqueia, descubra se o operador continuou a entregar no caminho sobrevivente. Se a sessão morre enquanto a segunda ligação está inativa, o operador nunca a usou. Se a sessão sobrevive mas os dados chegam fora de ordem ou duplicados, o operador está a mover pacotes sem um contrato ao nível da ligação. Os carimbos temporais de ambos os lados normalmente esclarecem isso.

Essa distinção decide a correção. Um problema de encaminhamento ou de política exige uma mudança de seleção de caminho; uma camada de ordenação e recuperação em falta exige outro transporte, não um buffer maior.

Garantia um: um fluxo de bytes ao nível da ligação

Se a VPN precisa de um fluxo ordenado e fiável, o operador tem de identificar intervalos de bytes acima do caminho individual. Cada ligação TCP subjacente numera apenas os seus próprios segmentos, pelo que um recetor não consegue reordenar entre caminhos apenas com esses números.

O Multipath TCP é o exemplo normalizado. Apresenta um fluxo de bytes fiável enquanto coordena vários subfluxos TCP, com mapeamento de sequência e confirmação ao nível dos dados. A aplicação lê um fluxo, não o subfluxo que por acaso entregou um pedaço primeiro.

No Linux, o MPTCP é opt-in por socket através de IPPROTO_MPTCP. Quando a negociação não consegue usar comportamento multipath, a alternativa documentada é TCP comum, o que significa que a aplicação pode continuar a funcionar por um caminho sem nunca usar o segundo. Verifique que comportamento o socket implementado realmente negociou em vez de assumir que a definição do kernel se aplicou.

Garantia dois: ordenação, duplicação e recuperação

Caminhos com atrasos e taxas de perda diferentes obrigam o operador a armazenar, reordenar e retransmitir. O contrato tem de indicar quanta memória intermédia é permitida, que contrapressão a aplicação vê e que caminho transporta uma retransmissão.

Um caminho que continua ligado mas deixa de entregar é mais difícil do que um fecho limpo. O operador tem de o detetar, mover os dados pendentes e evitar esperar para sempre por um segmento que nunca chegará. Uma verificação simples de que ambas as ligações estão ativas não cobre este estado.

A duplicação precisa da sua própria regra. Enviar a mesma carga por ambos os caminhos pode melhorar a latência, mas o recetor tem de suprimir a cópia antes de esta chegar à VPN. O anti-replay do IPsec é opcional por associação de segurança e verifica os números de sequência; uma camada de duplicação que reordena ou repete pacotes pode ativá-lo ou esconder o problema até o túnel cair.

Garantia três: identidade de endpoint e junção de caminhos

O par precisa de uma forma estável de reconhecer a sessão quando aparece um novo caminho. Se cada caminho for autenticado como um túnel separado, a VPN pode ver duas sessões em vez de uma. Se o operador junta caminhos sob uma sessão, tem de definir como o novo caminho é autenticado e o que acontece ao antigo.

Registe que endereços e identificadores permanecem estáveis: o endpoint do túnel, o identificador de sessão do operador e qualquer proxy pelo meio. Um proxy acrescenta outra fronteira de disponibilidade e confiança mesmo quando nunca vê a carga protegida.

É aqui que também reside a política. Um caminho que se junta a partir de uma rede inesperada pode ser tecnicamente válido e ainda assim violar o modelo de confiança pretendido. Decida se os novos caminhos são aceites automaticamente, exigem autenticação ou são recusados.

Garantia quatro: comportamento limitado em caso de falha

Teste uma falha total de caminho, não apenas um caminho lento. O caminho sobrevivente deve transportar a sessão sem crescimento ilimitado de memória, e a recuperação não deve depender de um temporizador mais longo do que a aplicação tolera. Quando o caminho falhado regressa, o operador tem de decidir se reequilibra ou deixa o fluxo onde está.

Defina limites para armazenamento intermédio, retransmissão e número de caminhos, e verifique-os sob perda, reordenação, duplicação e desequilíbrio de atraso. A largura de banda agregada é o número menos interessante aqui; a continuidade de entrega e os limites de memória são o contrato.

Mantenha o estado de recuperação do operador separado do estado criptográfico da VPN. Uma camada de fiabilidade própria que substitua autenticação ou cifragem estabelecidas não é um atalho, e reutilizar números de sequência entre camadas torna a proteção contra repetições e o diagnóstico pouco fiáveis.

Aceite o operador com um plano de testes

Escreva as quatro garantias como verificações de passa ou falha: um fluxo ordenado, recuperação definida, identidade de sessão estável e comportamento de falha limitado. Execute cada verificação com um caminho degradado e depois com um caminho removido.

Uma única transferência de ficheiro bem-sucedida através de uma mudança de caminho não prova funcionamento contínuo. Repita a transferência enquanto alterna o caminho preferido, e inspecione tanto a visão do operador como os contadores da própria VPN. Se os dois não concordarem sobre que caminho transportou os dados, o contrato ainda não é observável.

Guarde a matriz aprovada com a implantação. Diz ao próximo engenheiro que comportamento foi prometido, que combinações de caminhos foram testadas e que modo de falha continua sem suporte, sem outra ronda de suposições a partir das luzes de estado das ligações.