Canal de controlo e canal de dados VPN: verifique a camada certa

O cliente diz ligado, o servidor vê um par e a aplicação continua sem alcançar nada. Nesse ponto, a pergunta útil não é qual cifra mudar, mas qual canal falhou. OpenVPN nomeia duas funções explicitamente: um canal de controlo que negoceia e gere a sessão, e um canal de dados que transporta o tráfego protegido. IKEv2 exprime uma divisão semelhante através da associação IKE e da associação CHILD. Faça as verificações abaixo por ordem, porque uma correção do caminho de dados aplicada a uma falha do caminho de controlo desperdiça uma janela de mudança.

Nomeie o canal antes de o depurar

O lado de controlo negoceia o material de segurança, autentica os pares e gere a ligação. O lado de dados transporta o tráfego selecionado assim que existe o estado necessário.

Falham de forma diferente. Uma falha de controlo costuma deixá-lo sem qualquer sessão utilizável, ou com uma sessão que renegocia em ciclo. Uma falha de dados deixa uma sessão que parece saudável enquanto os pacotes são descartados, mal encaminhados ou protegidos com parâmetros que o outro lado não aceitará. A linha de registo que está a ler diz-lhe em qual dos dois casos está, por isso leia o rótulo antes do texto do erro.

Verifique a troca de controlo

Confirme que o aperto de mão se completa e que ambos os lados concordam quanto ao transporte, à versão de TLS e ao método de autenticação. Os registos do OpenVPN imprimem linhas separadas para o canal de controlo e para o canal de dados, e é na linha de controlo que aparece uma divergência de certificado, de versão de TLS ou de tls-crypt.

Se a troca de controlo falhar, olhe para a porta alcançável, para a cadeia de certificados e as suas datas de validade, para o relógio do sistema, para a sobreposição de cifras entre cliente e servidor e para qualquer chave tls-auth ou tls-crypt. Uma cadeia de certificados grande também pode falhar na MTU do caminho antes de qualquer autenticação terminar, o que parece um tempo limite e não um erro criptográfico.

Corrija as falhas de controlo com definições de controlo. Aumentar a cifra de dados ou suavizar a política de autenticação de dados não concluirá um aperto de mão que nunca passou da troca de certificados.

Verifique o canal de dados em separado

Com a sessão ativa, confirme a cifra e o modo de dados negociados, a derivação de chaves e o comportamento de renovação de chave. No OpenVPN, a linha do canal de dados indica a cifra e o tamanho de chave que foram realmente inicializados, e podem diferir da primeira cifra do perfil.

Depois verifique o que a sessão instalou. Um PUSH_REPLY pode acrescentar rotas, um servidor DNS e uma diretiva redirect-gateway, e qualquer um deles pode enviar tráfego para onde a aplicação não o consegue usar. Para IKEv2, a pergunta equivalente é se os seletores da associação CHILD correspondem aos endereços do fluxo real.

tls-auth e tls-crypt pertencem ao canal de controlo. Autenticam ou cifram o aperto de mão e não selecionam a cifra de dados da aplicação. Se acrescentar um deles à espera de uma alteração no caminho de dados, a única coisa que alterou foi o aperto de mão.

Relacione os nomes com IKEv2 e OpenVPN

O IKEv2 tem uma associação de segurança IKE e uma ou mais associações CHILD. A associação IKE transporta as trocas de controlo; a associação CHILD transporta o tráfego protegido e os seus seletores. São negociadas e recebem chaves novas segundo calendários separados, pelo que uma pode estar saudável enquanto a outra não está.

O ESP não tem dentro de si um canal de controlo ao estilo TLS. O protocolo de controlo é o IKE, e o ESP é a carga protegida. Chamar ao ESP o canal de dados é uma abreviatura solta que se torna confusa quando se lê uma captura de pacotes, porque a captura mostra as mensagens IKE e os pacotes ESP como protocolos diferentes no fio.

Mantenha a correspondência explícita nas suas notas: o canal de controlo do OpenVPN e a IKE SA são o lado de gestão, o canal de dados do OpenVPN e a CHILD SA são o lado do tráfego, e as implementações não são intercambiáveis mesmo quando a divisão parece semelhante.

Deixe de alterar a definição errada

Percorra o caminho numa só direção: troca de controlo, proteção de dados, encaminhamento e depois resolução de nomes. Pare na primeira etapa que falhar e corrija apenas essa etapa. Uma sessão ligada com um ping a funcionar até ao gateway mas sem tráfego da aplicação é um problema de encaminhamento ou de seletores, não de aperto de mão.

Escreva as provas de cada etapa em separado no ticket: a linha de registo do controlo, os parâmetros de dados negociados, as rotas instaladas e um pedido real. Essa estrutura impede que uma verificação de identidade que funciona seja enfraquecida para reparar um problema de encaminhamento posterior que nunca causou, e impede que uma alteração da cifra de dados seja vendida como correção de um erro de certificado.

A documentação do protocolo OpenVPN é a referência para a divisão entre controlo e dados; use-a quando a interface de um fornecedor empregar outras palavras para as mesmas duas funções.