Non, unha cadea de conexión non pode iniciar o teu túnel VPN

Os desenvolvedores seguen buscando o lugar onde unha cadea de conexión, un URL JDBC ou unha entrada de tnsnames.ora selecciona a VPN. Ese lugar non existe. O túnel establéceo o sistema operativo ou un cliente do provedor que rexistra un adaptador virtual, e cada biblioteca de base de datos por riba usa a capa de socket resultante. Unha cadea de conexión nomea un host, un porto e unha credencial, e ese é todo o vocabulario.

Mito: a cadea de conexión pode seleccionar un túnel

O controlador abre un socket TCP cara a un host e un porto. Non ten API para levantar un túnel, nin campo para un perfil de túnel, nin forma de autenticarse nunha pasarela VPN.

Por iso as ferramentas compórtanse igual cando existe unha ruta. SSMS, DBeaver, Eclipse Data Tools e un sqlcmd corrente actúan coma se o servidor estivese na rede local, porque desde o punto de vista do socket está. O adaptador virtual fixo accesible a subrede da base de datos, e o controlador nunca sabe como.

Tamén explica por que unha cadea de conexión non pode reparar un túnel caído. Cando a ligazón morre, o controlador informa dun tempo de espera ou dun erro de rede xeral, e o código da aplicación que trata iso como un problema de consulta reintenta a capa equivocada para sempre.

Levanta o túnel antes de que se execute o controlador

Conecta a VPN a nivel de sistema operativo, seguindo as instrucións do provedor ou do equipo de rede, e só entón abre a ferramenta. Na práctica iso significa que existe unha ruta cara á subrede da base de datos antes de que o controlador resolva o nome do host.

Mantén a supervisión do túnel fóra da aplicación. Un servizo PHP ou Java que intenta levantar a ligazón por si mesmo codifica o comportamento dun provedor dentro do código de negocio, e cada conmutación por erro convértese nunha versión da aplicación. Un supervisor que posúe o túnel, vixíao e reiníciao é un asunto aparte do camiño da consulta.

Comproba a ruta antes de culpar o controlador: se o host non resolve ou o porto non responde desde a shell, ningunha cadea de conexión cambiará iso.

Mito: un fallo de autenticación de Windows significa que a ruta está rota

A autenticación de Windows a través dunha VPN a miúdo falla cun erro que parece unha avaría de rede, e a ruta está ben. Cando a conta pertence a outro dominio e o portátil non pode unirse a el, inicia o cliente con credenciais explícitas en lugar da identidade da sesión de escritorio.

runas /noprofile /netonly /user:CORP\dbreader "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"

O conmutador /netonly conserva esas credenciais só para a autenticación remota. Confirma o que o servidor recibiu realmente con SELECT SUSER_SNAME() en lugar de confiar no diálogo de conexión. Infórmase de que gardar a credencial do enderezo do servidor en Windows Credential Manager funciona para SSMS pero non sempre para un servizo que se executa baixo outra conta, así que comproba que identidade usa o proceso antes de cambiar o inicio de sesión.

A latencia converte un cursor do lado do servidor nun tempo de espera

Un cursor do lado do servidor pide á base de datos que reteña o resultado e o recupere de forma incremental, o que converte un resultado grande en moitas viaxes de ida e volta pequenas. Nunha LAN iso é barato. Por un túnel con decenas de milisegundos de latencia engadida, a mesma consulta pode superar o tempo de espera do comando sen transferir case nada de datos.

Cambia a un cursor do lado do cliente, ou sube o tamaño de recuperación e agrupa as filas, e o número de viaxes baixa. O pescozo de botella é o número de intercambios, non a velocidade nominal da ligazón, así que medir o rendemento enganarate mentres que medir as viaxes non. Proba co conxunto de resultados máis grande que os teus usuarios realmente extraen, non cunha consulta dunha fila que volve ao instante. Se o tempo de espera se move pero non desaparece, sube o tempo de espera do comando e o tamaño de recuperación á vez e volve medir.

A mesma aritmética aplícase aos ORM falangueiros e a calquera cliente que emite unha sentenza por fila. Se o plan de consulta é bo e a transferencia é pequena, conta os intercambios de rede antes de axustar a base de datos.

Comproba o porto, a instancia e o filtro local

Unha instancia con nome escoita nun porto dinámico, así que confirma o porto en lugar de supoñer 1433. Nunha instancia predeterminada o valor pódese ler do valor de rexistro TcpPort baixo a clave SuperSocketNetLib da instancia. Para Oracle, verifica que o host de tnsnames.ora resolve, que o enderezo responde e que o porto do listener está permitido; 1521 é un valor predeterminado habitual, non unha garantía.

Despois descarta a lista de acceso do propio túnel e, por último, un antivirus local ou unha devasa de host que bloquea a conexión mesmo cando cliente e servidor son a mesma máquina. Captura a etapa que falla antes de cambiar a configuración, porque a resolución de nomes, a accesibilidade TCP e TLS ou o inicio de sesión fallan cada un cunha mensaxe distinta.

Escribe a etapa no tícket. Se non, a seguinte persoa repetirá a mesma procura de cadea de conexión coa que comezou todo.