No, una cadena de conexión no puede iniciar tu túnel VPN
La VPN la posee el sistema operativo o un cliente, nunca el controlador. Levanta primero el túnel, pasa credenciales de dominio con netonly y después revisa los viajes de ida y vuelta del cursor.
Los desarrolladores siguen buscando el lugar donde una cadena de conexión, una URL JDBC o una entrada de tnsnames.ora selecciona la VPN. Ese lugar no existe. El túnel lo establece el sistema operativo o un cliente del proveedor que registra un adaptador virtual, y cada biblioteca de base de datos por encima usa la capa de socket resultante. Una cadena de conexión nombra un host, un puerto y una credencial, y ese es todo el vocabulario.
Mito: la cadena de conexión puede seleccionar un túnel
El controlador abre un socket TCP hacia un host y un puerto. No tiene API para levantar un túnel, ni campo para un perfil de túnel, ni forma de autenticarse en una puerta de enlace VPN.
Por eso las herramientas se comportan igual cuando existe una ruta. SSMS, DBeaver, Eclipse Data Tools y un sqlcmd corriente actúan como si el servidor estuviera en la red local, porque desde el punto de vista del socket lo está. El adaptador virtual hizo accesible la subred de la base de datos, y el controlador nunca sabe cómo.
También explica por qué una cadena de conexión no puede reparar un túnel caído. Cuando el enlace muere, el controlador informa de un tiempo de espera o de un error de red general, y el código de la aplicación que trata eso como un problema de consulta reintenta la capa equivocada para siempre.
Levanta el túnel antes de que se ejecute el controlador
Conecta la VPN a nivel de sistema operativo, siguiendo las instrucciones del proveedor o del equipo de red, y solo entonces abre la herramienta. En la práctica eso significa que existe una ruta hacia la subred de la base de datos antes de que el controlador resuelva el nombre del host.
Mantén la supervisión del túnel fuera de la aplicación. Un servicio PHP o Java que intenta levantar el enlace por sí mismo codifica el comportamiento de un proveedor dentro del código de negocio, y cada conmutación por error se convierte en una versión de la aplicación. Un supervisor que posee el túnel, lo vigila y lo reinicia es un asunto aparte del camino de la consulta.
Comprueba la ruta antes de culpar al controlador: si el host no resuelve o el puerto no responde desde el shell, ninguna cadena de conexión cambiará eso.
Mito: un fallo de autenticación de Windows significa que la ruta está rota
La autenticación de Windows a través de una VPN a menudo falla con un error que parece una avería de red, y la ruta está bien. Cuando la cuenta pertenece a otro dominio y el portátil no puede unirse a él, inicia el cliente con credenciales explícitas en lugar de la identidad de la sesión de escritorio.
runas /noprofile /netonly /user:CORP\dbreader "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"El conmutador /netonly conserva esas credenciales solo para la autenticación remota. Confirma lo que el servidor recibió realmente con SELECT SUSER_SNAME() en lugar de confiar en el diálogo de conexión. Se informa de que guardar la credencial de la dirección del servidor en Windows Credential Manager funciona para SSMS pero no siempre para un servicio que se ejecuta con otra cuenta, así que comprueba qué identidad usa el proceso antes de cambiar el inicio de sesión.
La latencia convierte un cursor de servidor en un tiempo de espera
Un cursor del lado del servidor pide a la base de datos que retenga el resultado y lo recupere de forma incremental, lo que convierte un resultado grande en muchos viajes de ida y vuelta pequeños. En una LAN eso es barato. Por un túnel con decenas de milisegundos de latencia añadida, la misma consulta puede superar el tiempo de espera del comando sin transferir casi nada de datos.
Cambia a un cursor del lado del cliente, o sube el tamaño de recuperación y agrupa las filas, y el número de viajes baja. El cuello de botella es el número de intercambios, no la velocidad nominal del enlace, así que medir el rendimiento te engañará mientras que medir los viajes no. Prueba con el conjunto de resultados más grande que tus usuarios realmente extraen, no con una consulta de una fila que vuelve al instante. Si el tiempo de espera se mueve pero no desaparece, sube el tiempo de espera del comando y el tamaño de recuperación a la vez y vuelve a medir.
La misma aritmética se aplica a los ORM charlatanes y a cualquier cliente que emite una sentencia por fila. Si el plan de consulta es bueno y la transferencia es pequeña, cuenta los intercambios de red antes de ajustar la base de datos.
Comprueba el puerto, la instancia y el filtro local
Una instancia con nombre escucha en un puerto dinámico, así que confirma el puerto en lugar de suponer 1433. En una instancia predeterminada el valor puede leerse del valor de registro TcpPort bajo la clave SuperSocketNetLib de la instancia. Para Oracle, verifica que el host de tnsnames.ora resuelva, que la dirección responda y que el puerto del listener esté permitido; 1521 es un valor predeterminado habitual, no una garantía.
Después descarta la lista de acceso del propio túnel y, por último, un antivirus local o un cortafuegos de host que bloquee la conexión incluso cuando cliente y servidor son la misma máquina. Captura la etapa que falla antes de cambiar la configuración, porque la resolución de nombres, la accesibilidad TCP y TLS o el inicio de sesión fallan cada uno con un mensaje distinto.
Escribe la etapa en el tique. Si no, la siguiente persona repetirá la misma búsqueda de cadena de conexión con la que empezó todo.