OpenVPN: ejecutar un archivo .ovpn en Linux y entender un fallo

Ha recibido un archivo .ovpn, está iniciando OpenVPN en una VM Debian o Ubuntu, luego el terminal muestra un error o se queda atascado antes de la conexión. El archivo puede ser válido mientras apunte a un certificado ausente, un puerto filtrado o una ruta que interrumpe su sesión SSH. Controle el perfil, anote el primer error, luego verifique la ruta y el servicio interno después de la conexión.

Leer el archivo .ovpn antes de iniciar OpenVPN

Mantenga una consola local, una consola de proveedor, iDRAC/IPMI o una red de administración distinta ya validada. Realice la prueba desde este acceso independiente. redirect-gateway puede estar escrito en el archivo o enviado por el servidor después de la conexión. La ruta por defecto puede entonces pasar a través del túnel. Una segunda sesión SSH que use la misma ruta no es un acceso de respaldo.

Si está conectado por SSH antes de la prueba, muestre y anote la dirección del cliente. Desde la consola de control utilizada después de la conexión, redefina esta dirección antes de verificar su ruta. Una consola de recuperación permite volver al servidor, no garantiza que su sesión SSH permanezca abierta.

# En la sesión SSH antes del lanzamiento:
printf '%sn' "$SSH_CLIENT"
# En la consola de control después de la conexión:
SSH_CLIENT_IP='198.51.100.42' # reemplace por la dirección del cliente anotada
ip route get "$SSH_CLIENT_IP"

Coloque el archivo en un directorio reservado a su cuenta y limite sus derechos si se integran claves. No incluya identificación ni contraseña en el archivo de demostración o en un repositorio Git.

mkdir -p ~/vpn-test
install -m 600 /ruta/recibida/client.ovpn ~/vpn-test/client.ovpn
cd ~/vpn-test
grep -nE '^[[:space:]]*(remote|proto|port|ca|cert|key|pkcs12|tls-auth|tls-crypt|tls-verify|auth-user-pass|auth-user-pass-verify|redirect-gateway|redirect-private|route|route-ipv6|route-gateway|route-table|route-noexec|route-nopull|pull-filter|config|plugin|script-security|up|down|route-up|route-pre-down|ipchange|dns-updown|management|daemon|log|log-append|syslog|status|writepid|askpass|cd|chroot|user|group|learn-address|client-connect|client-disconnect)' client.ovpn

Esta lectura muestra el host remoto, el protocolo, los archivos de certificados y el modo de autenticación sin mostrar su contenido. Si config carga otro archivo, léalo nuevamente desde el directorio del perfil, vuelva a hacer este filtro y siga cada config hasta el último archivo. Toda la cadena debe ser comprendida antes del lanzamiento. up, down, route-up, route-pre-down, ipchange y tls-verify lanzan comandos externos. plugin carga una biblioteca en el proceso OpenVPN. management abre una interfaz de control que no debe ser expuesta. Un perfil cliente que contenga learn-address, client-connect, client-disconnect o auth-user-pass-verify es rechazado para este diagnóstico. Deténgase también si alguna de las otras rutas es desconocida. Los scripts externos requieren un valor script-security de 2 o 3, valor que el perfil puede fijar por sí mismo. Verifique también auth-user-pass: sin argumento, OpenVPN pedirá las credenciales en el prompt; con un camino, leerá este archivo y transmitirá su contenido al servidor del perfil. El lanzamiento con sudo sigue siendo normal para crear la interfaz y las rutas, pero ningún archivo referenciado debe ser desconocido.

# Por cada ruta encontrada después de « config », desde ~/vpn-test:
sed -n '1,220p' ruta-incluida.conf

Un archivo cuya procedencia o directrices siguen siendo desconocidas nunca debe ser lanzado en un servidor de producción ni en una máquina cuyo acceso SSH sea importante. El primer intento se realiza en una VM desechable con consola independiente. Esta lectura reduce el riesgo, no transforma un perfil arbitrario en un perfil seguro. También rechace daemon, log, log-append y syslog para este diagnóstico: desplazan los mensajes fuera del terminal y pueden dejar el proceso en segundo plano.

Si el perfil referencia rutas relativas, no mueva solamente client.ovpn. Conserve el directorio recibido en un lugar controlado o copie cada dependencia revisada con la misma estructura y derechos restrictivos. Por ejemplo, un perfil que cita ca ca.crt debe encontrar ca.crt en ~/vpn-test.

install -m 600 /ruta/recibida/ca.crt ~/vpn-test/ca.crt

Una dependencia ausente o ilegible es un fallo del perfil, distinto de un error TLS después del intento de red. Un archivo .ovpn también puede incluir los certificados entre etiquetas, este control no mostrará entonces ninguna ruta externa.

find ~/vpn-test -maxdepth 1 -type f -printf '%f %mn'
# Para proto udp4/tcp4 :
getent ahostsv4 vpn.ejemplo.net
# Para proto udp6/tcp6 :
getent ahostsv6 vpn.ejemplo.net
ip -brief link show > ~/vpn-test/links-before.txt

Reemplace el host y la familia por los valores de remote y proto. Un perfil puede contener varias líneas remote. Si la familia sigue abierta, verifique ambas salidas y conserve la dirección anunciada por OpenVPN en el registro. La conexión OpenVPN en sí sigue siendo la prueba útil del protocolo y del puerto, ya sea UDP o TCP.

Iniciar el cliente en primer plano y registrar

Inicie el cliente en primer plano. El terminal debe mostrar la dirección contactada y el primer error explotable. Instale el paquete si openvpn está ausente :

command -v openvpn || { sudo apt update && sudo apt install openvpn; }
sudo openvpn --config ~/vpn-test/client.ovpn --verb 3

Con --verb 3, mantenga el primer error explícito, la dirección del servidor y la fase en la que el cliente se detiene.

• Error de opciones o un archivo no encontrado indican un camino, una directriz o un certificado a corregir antes de un nuevo intento.
• Error TLS después del intento de conexión solicita un control del servidor, del puerto, del protocolo UDP/TCP, del filtrado de red, de tls-auth o tls-crypt, de los certificados, de la hora del sistema y de los parámetros criptográficos del perfil.
• Una solicitud de identificación puede venir de auth-user-pass. Introduzca en el prompt o use el mecanismo previsto por su proveedor, sin añadir el secreto a client.ovpn.
• El mensaje Initialization Sequence Completed confirma que el cliente ha terminado su inicialización. No prueba aún que el recurso interno esperado sea accesible.

Mantenga el comando abierto durante el siguiente control. Deténgalo con Ctrl+C solo después de haber verificado la interfaz, las rutas y el servicio interno.

Verificar la interfaz y la ruta después de la conexión

Registre las interfaces antes de la conexión, luego compárelas después. tun transporta paquetes IP, tap emula una interfaz Ethernet. La directiva dev también puede imponer un nombre. Utilice únicamente el nombre realmente creado. ip route get muestra el dispositivo que Linux elegiría, sin enviar paquetes.

# Después de « Initialization Sequence Completed » :
ip -brief link show | diff -u ~/vpn-test/links-before.txt -
VPN_IF='nombre-de-la-interfaz-creada'
ip -brief address show dev "$VPN_IF"
ip route get 10.8.0.10
ip route get 1.1.1.1
ip route get "$SSH_CLIENT_IP"

Reemplace 10.8.0.10 por un objetivo interno documentado por el equipo que proporciona el VPN. Su ruta debe mencionar la interfaz del túnel si esta red pasa a través de OpenVPN. Revise también la ruta hacia SSH_CLIENT_IP si tenía una sesión remota antes de la prueba.

La ruta no prueba que el servicio interno responda. Luego, pruebe el servicio esperado con la dirección y el puerto documentados por su equipo. Para un servicio HTTPS que expone una página de salud, por ejemplo :

getent hosts intranet.ejemplo.lan
curl --fail --silent --show-error --connect-timeout 5 --max-time 10 --output /dev/null --write-out '%{http_code}n' https://intranet.ejemplo.lan:443/health

Reemplace este nombre, el puerto y la ruta por los del servicio real. El primer comando debe devolver una dirección interna. El segundo debe mostrar el código esperado por este servicio, por ejemplo 200 o 204. curl también verifica el certificado TLS: instale la CA interna o use la documentación del servicio si es necesario, sin añadir --insecure. Para un DNS interno, consulte mejor un nombre y un resolvedor documentados por su equipo.

Elegiría este lanzamiento puntual antes de un servicio openvpn-client@... en un servidor, ya que el diagnóstico permanece separado de la puesta en marcha. Después de Ctrl+C, verifique que la interfaz ha desaparecido, que la ruta hacia el objetivo interno ya no utiliza el túnel y que la ruta hacia la dirección SSH anotada vuelve al dispositivo esperado. Un perfil con scripts down o route-pre-down requiere este control, no permite suponer que la limpieza ha tenido éxito.

ip link show "$VPN_IF"
ip route get 10.8.0.10
ip route get "$SSH_CLIENT_IP"

El primer comando debe indicar que la interfaz ya no existe. Compare las dos rutas con sus salidas anotadas antes y durante el túnel. Una ruta aún relacionada con la interfaz eliminada o un script de limpieza en error requiere una verificación antes de un nuevo intento.