Cómo verificar el servidor de un perfil OpenVPN antes de importarlo

Alguien le envía un perfil, usted lo importa y treinta segundos después un cliente marca un destino que nadie comprobó. Lea primero el archivo en un editor de texto, porque todo lo que importa cabe en un puñado de directivas: remote, proto, port, ca, cert, tls-crypt y verify-x509-name. Todo lo demás son valores por defecto, y ahí es donde viven las sorpresas.

Enumere cada extremo que el archivo puede usar

Empiece por los extremos, porque un perfil puede contener varios. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn imprime cada candidato en el orden del archivo, incluidos los anidados dentro de bloques <connection> en línea.

Cuando una directiva omite el puerto, el cliente recurre al valor por defecto del oyente, así que solo remote vpn.example.com significa el puerto 1194 con cualquier proto que aparezca más adelante en el archivo. Varias líneas simples remote son alternativas: el cliente las prueba en orden salvo que remote-random las mezcle, y nunca sustituye en silencio el host de otro operador. Dos líneas remote en dominios no relacionados es el punto donde uno se detiene y pregunta cuál se quería.

Fíjese también en la escritura de proto. tcp se acepta como sinónimo del tcp-client del lado cliente, pero tcp-server en un perfil de cliente es un error de configuración que suele colgarse en vez de fallar limpiamente.

Confirme el nombre y después el puerto

dig +short vpn.example.com le dice si el nombre existe y qué direcciones devuelve, y un extremo con varias direcciones o detrás de un proxy puede devolver varias legítimamente. La resolución es un requisito previo, no una prueba de propiedad; cualquiera puede apuntar un nombre a una dirección, y una dirección puede responder por muchos nombres.

Después compruebe el oyente en el puerto que encontró, de acuerdo con el transporte. Por TCP, openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com imprime la cadena que presenta el servidor. Por UDP hace falta DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 ejecuta el mismo saludo por datagramas. Un saludo completado demuestra que algo escucha y tiene un certificado, lo cual es más de lo que muestra un ping y menos de lo que exigen los propios ajustes de confianza del perfil.

Cuando el saludo falla y el host responde al ping, el puerto probablemente es incorrecto o está filtrado. Tómelo como motivo para pedir el puerto correcto, no como invitación a barrer los cercanos. nc -vzu también informa de éxito en algunas pilas sin que nada escuche, así que una sonda UDP desnuda no significa nada sin un saludo detrás.

Lea los pines de confianza aparte de la dirección

La dirección decide adónde va el cliente; el bloque de confianza decide en quién cree al llegar. verify-x509-name "vpn.example.com" name fija el nombre común del sujeto, y remote-cert-tls server exige el uso extendido de la clave para la autenticación del servidor. Un perfil que le entregue un operador debería llevar ambos.

Busque ca, un bloque <ca> en línea y tls-crypt o tls-auth. Un perfil que usa tls-auth necesita key-direction 1 en el cliente cuando el lado servidor usa la dirección 0, y un desajuste hace fallar el saludo con un error TLS que se lee como un defecto de certificado. Un CA en línea que no pertenece al operador cuyo nombre acaba de resolver significa que el archivo se armó con dos fuentes, y ese es el caso que conviene rechazar de plano.

verify-x509-name acepta los modos name, name-prefix o subject, y el último espera un nombre distinguido completo en el orden exacto en que lo imprime el servidor. Elija un modo que encaje con la forma del valor, porque el cliente rechaza cada conexión en lugar de avisar de un casi acierto. Para un archivo que usted no escribió, name con un nombre de host simple es la opción menos sorprendente.

Revise las opciones que fallan en silencio

OpenVPN 2.6 negocia los cifrados mediante data-ciphers, y un perfil que solo lleva una línea antigua cipher AES-256-CBC puede completar el canal de control y luego atascarse en los datos. Leer ese valor le dice si el archivo es anterior al servidor al que se une; la página de manual de 2.6 enumera el orden de negociación si necesita citárselo al operador.

auth-user-pass sin nombre de archivo significa que el cliente preguntará, así que un perfil que parece autosuficiente aún necesita credenciales. auth-user-pass credentials.txt significa que espera un archivo que probablemente no le enviaron. nobind y resolv-retry infinite son corrientes e inofensivos, mientras que explicit-exit-notify es solo para UDP e inútil por TCP.

Nada de esto cambia adónde se conecta el perfil, pero cada uno cambia si se conecta o no, y ninguno es visible en el diálogo de importación del cliente.

Decida y luego anote lo que decidió

Tras esta lectura hay tres desenlaces y solo uno es importar. Cuando el extremo y los pines coinciden con instrucciones recibidas por un canal aparte, impórtelo. Cuando el extremo parece correcto pero los pines o el CA no coinciden, pida un archivo corregido. Cuando el archivo mezcla extremos o material de CA de fuentes distintas, bórrelo y pida una copia nueva.

Anote el hash que revisó, para que la siguiente persona sepa si el archivo cambió: sha256sum profile.ovpn, pegado junto al extremo en sus notas. Un perfil es un arreglo completo, no una lista de direcciones, así que nunca empalme un remote que funciona en el bloque de confianza de otro conservando sus credenciales.

Mantenga las claves privadas y las contraseñas fuera de capturas de pantalla e hilos de chat mientras compara notas. El extremo y las opciones no secretas bastan para hacer una pregunta precisa, y el resto pertenece al archivo.

Si acaba importándolo y el primer intento falla, ejecute el cliente con --verb 3 y lea las diez primeras líneas: la dirección remote resuelta, el proto negociado y el error TLS aparecen en ese orden, lo que le dice cuál de las comprobaciones anteriores se saltó.