Canle de control e canle de datos na VPN: comprobe a capa correcta

O cliente di conectado, o servidor ve un par e a aplicación segue sen alcanzar nada. Nese punto a pregunta útil non é que cifrado cambiar, senón que canle fallou. OpenVPN nomea dúas funcións de forma explícita: unha canle de control que negocia e xestiona a sesión, e unha canle de datos que transporta o tráfico protexido. IKEv2 expresa unha división semellante mediante a asociación IKE e a asociación CHILD. Faga as comprobacións seguintes por orde, porque unha corrección da ruta de datos aplicada a un fallo da ruta de control malgasta unha xanela de cambio.

Nomee a canle antes de depurala

O lado de control negocia o material de seguridade, autentica os pares e xestiona a conexión. O lado de datos transporta o tráfico seleccionado unha vez que existe o estado necesario.

Fallan de forma distinta. Un fallo de control adoita deixarlle sen ningunha sesión utilizábel, ou cunha sesión que renegocia en bucle. Un fallo de datos deixa unha sesión que parece sa, mentres os paquetes se descartan, se encamiñan mal ou se protexen con parámetros que o outro extremo non aceptará. A liña de rexistro que está a ler di en cal dos dous está, así que lea a etiqueta antes do texto do erro.

Comprobe o intercambio de control

Confirme que o aperto de mans se completa e que ambas as partes coinciden no transporte, na versión de TLS e no método de autenticación. Os rexistros de OpenVPN imprimen liñas separadas da canle de control e da canle de datos, e a liña de control é onde aparece unha discrepancia de certificado, de versión de TLS ou de tls-crypt.

Se o intercambio de control falla, mire o porto accesíbel, a cadea de certificados e as súas datas de validez, o reloxo do sistema, o solapamento de cifrados entre cliente e servidor e calquera chave tls-auth ou tls-crypt. Unha cadea de certificados grande tamén pode fallar na MTU da ruta antes de que se complete calquera autenticación, o que parece un tempo de espera e non un erro criptográfico.

Corrixa os fallos de control con axustes de control. Subir o cifrado de datos ou relaxar a política de autenticación de datos non completará un aperto de mans que nunca superou o intercambio de certificados.

Comprobe a canle de datos por separado

Coa sesión activa, confirme o cifrado e o modo de datos negociados, a derivación de chaves e o comportamento de renovación de chave. En OpenVPN, a liña da canle de datos indica o cifrado e o tamaño de chave que realmente se inicializaron, e poden diferir do primeiro cifrado do perfil.

Despois comprobe que instalou a sesión. Un PUSH_REPLY pode engadir rutas, un servidor DNS e unha directiva redirect-gateway, e calquera delas pode enviar tráfico a onde a aplicación non o pode usar. Para IKEv2, a pregunta equivalente é se os selectores da asociación CHILD coinciden cos enderezos do fluxo real.

tls-auth e tls-crypt pertencen á canle de control. Autentican ou cifran o aperto de mans e non seleccionan o cifrado de datos da aplicación. Se engade un deles esperando un cambio na ruta de datos, o único que cambiou é o aperto de mans.

Relacione os nomes con IKEv2 e OpenVPN

IKEv2 ten unha asociación de seguridade IKE e unha ou máis asociacións CHILD. A asociación IKE transporta os intercambios de control; a asociación CHILD transporta o tráfico protexido e os seus selectores. Negócianse e renóvanse as chaves con calendarios separados, así que unha pode estar sa mentres a outra non o está.

ESP non ten dentro unha canle de control ao estilo de TLS. O protocolo de control é IKE, e ESP é a carga protexida. Chamar a ESP a canle de datos é unha abreviatura laxa que se volve confusa ao ler unha captura de paquetes, porque a captura mostra as mensaxes IKE e os paquetes ESP como protocolos distintos no cable.

Manteña a correspondencia explícita nas súas notas: a canle de control de OpenVPN e o IKE SA son o lado de xestión, a canle de datos de OpenVPN e o CHILD SA son o lado do tráfico, e as implementacións non son intercambiábeis aínda que a división pareza similar.

Deixe de cambiar o axuste equivocado

Percorra a ruta nunha soa dirección: intercambio de control, protección de datos, encamiñamento e despois resolución de nomes. Détase na primeira etapa que falle e corrixa só esa etapa. Unha sesión conectada cun ping que funciona ata a pasarela pero sen tráfico da aplicación é un problema de encamiñamento ou de selectores, non de aperto de mans.

Escriba a evidencia de cada etapa por separado no ticket: a liña de rexistro de control, os parámetros de datos negociados, as rutas instaladas e unha petición real. Esa estrutura evita que se debilite unha comprobación de identidade que funciona para reparar un problema de encamiñamento posterior que nunca causou, e evita que se venda un cambio de cifrado de datos como solución dun erro de certificado.

A documentación do protocolo OpenVPN é a referencia para a división entre control e datos; úsea cando a interface dun provedor empregue outras palabras para as mesmas dúas funcións.