Usamos OpenVPN: ¿protocolo, motor o aplicación? Qué preguntar en su lugar

La frase «usamos OpenVPN» llega en tiques, formularios de compra y documentos de incorporación, y en cada uno responde a una pregunta distinta. A veces nombra un protocolo de transporte, a veces el software de una pasarela y a veces la aplicación que debe instalar una persona nueva. Esos tres hechos llevan a pasos siguientes distintos, y preguntar cuál se quiere decir cuesta menos tiempo que adivinarlo. El resto de la investigación se deduce de esa respuesta.

Empiece separando el rol de la marca, porque la marca cubre los tres.

El nombre cubre tres roles que fallan de forma distinta

Como protocolo, OpenVPN describe cómo los pares compatibles establecen un túnel y protegen lo que lo atraviesa. Como software, es una implementación que habla ese protocolo en rol de cliente o de servidor. Como cliente, es una aplicación que alguien instala, con su propia versión, su formato de perfil y sus peculiaridades de plataforma. Un fallo en un rol no implica un fallo en otro, y por eso «OpenVPN está caído» necesita un sujeto.

Pregunte qué puede ver quien lo reporta: un archivo de perfil, un programa instalado o una pasarela que administra. Ese único detalle le dice si el paso siguiente es un registro del cliente, una pregunta sobre el paquete o una comprobación del oyente en el lado del servidor.

OpenVPN 2 y OpenVPN 3 no son una pareja de actualización

OpenVPN 2.x funciona tanto en rol de servidor como de cliente, y es lo que todavía usa la mayoría de los despliegues de pasarela. OpenVPN 3 es una implementación aparte orientada al cliente, con su propia configuración y su propio modelo de sesión, no la siguiente versión que se instala sobre un servidor 2.x. OpenVPN Connect es una aplicación de cliente construida sobre el motor OpenVPN 3. Instalar cualquiera de ellas no crea un servicio de salida a internet; la salida es lo que haya configurado el operador.

La compatibilidad a nivel de protocolo no se extiende a las directivas del perfil, así que un perfil que se importa limpiamente puede fallar en una directiva que el cliente no implementa.

El transporte no es la aplicación que lleva dentro

La conexión exterior usa un transporte como UDP o TCP para llegar a un oyente configurado, y todo lo que el túnel transporta viaja dentro de él. Una petición web hecha a través de la VPN no necesita su propio oyente OpenVPN y no se convierte en un paquete OpenVPN por el cable. En modo TLS el canal de control negocia el material de claves mientras el canal de datos protege la carga útil, y es una separación que conviene mantener correcta al leer registros.

Confundir las capas produce peticiones como abrir un puerto para un sitio web que ya funciona a través del túnel. El puerto pertenece a la conexión exterior, no a la aplicación.

Qué puede prometer un perfil y qué no

Un perfil dice a un cliente cómo llegar a un servicio: punto final, transporte, material de identidad y a menudo algunas preferencias de enrutamiento y DNS. No dice nada sobre quién opera ese servicio ni sobre si la cuenta está autorizada. Las rutas, los ajustes del resolutor, las reglas de reenvío y la política de acceso deciden a qué llega realmente la sesión. Un perfil que se importa correctamente es el comienzo de una conexión funcional, no la prueba de que lo sea.

Cuando alguien pregunta si un recurso es alcanzable por la VPN, la respuesta depende de la política del servidor y no del archivo de configuración del cliente.

Pida lo que se puede aprovisionar

Convierta el nombre amplio en tres concreciones: el cliente y su versión, el perfil autorizado para ese cliente y el recurso al que la persona necesita llegar. Con ellas, el aprovisionamiento es una tarea concreta. Sin ellas, cada respuesta es una conjetura sobre qué OpenVPN quería decir la pregunta.

Anote la respuesta en la propia solicitud. El siguiente tique hará la misma pregunta de la misma manera ambigua.