Não, uma cadeia de conexão não pode iniciar seu túnel VPN

Desenvolvedores continuam procurando o lugar onde uma cadeia de conexão, uma URL JDBC ou uma entrada de tnsnames.ora seleciona a VPN. Esse lugar não existe. O túnel é estabelecido pelo sistema operacional ou por um cliente do fornecedor que registra um adaptador virtual, e cada biblioteca de banco de dados acima usa a camada de socket resultante. Uma cadeia de conexão nomeia um host, uma porta e uma credencial, e esse é todo o vocabulário.

Mito: a cadeia de conexão pode selecionar um túnel

O driver abre um socket TCP para um host e uma porta. Não tem API para levantar um túnel, nem campo para um perfil de túnel, nem forma de autenticar em um gateway VPN.

Por isso as ferramentas se comportam igual quando existe uma rota. SSMS, DBeaver, Eclipse Data Tools e um sqlcmd comum agem como se o servidor estivesse na rede local, porque do ponto de vista do socket ele está. O adaptador virtual tornou a sub-rede do banco de dados alcançável, e o driver nunca sabe como.

Também explica por que uma cadeia de conexão não consegue reparar um túnel caído. Quando o link morre, o driver relata um tempo limite ou um erro de rede geral, e o código da aplicação que trata isso como problema de consulta repete a camada errada para sempre.

Suba o túnel antes de o driver ser executado

Conecte a VPN no nível do sistema operacional, seguindo as instruções do provedor ou da equipe de rede, e só então abra a ferramenta. Na prática, isso significa que existe uma rota para a sub-rede do banco de dados antes de o driver resolver o nome do host.

Mantenha a supervisão do túnel fora da aplicação. Um serviço PHP ou Java que tenta levantar o link sozinho codifica o comportamento de um fornecedor no código de negócio, e cada failover vira uma versão da aplicação. Um supervisor que possui o túnel, o observa e o reinicia é um assunto separado do caminho da consulta.

Verifique a rota antes de culpar o driver: se o host não resolve ou a porta não responde pelo shell, nenhuma cadeia de conexão mudará isso.

Mito: uma falha de autenticação do Windows significa que a rota está quebrada

A autenticação do Windows através de uma VPN frequentemente falha com um erro que parece pane de rede, e a rota está bem. Quando a conta pertence a outro domínio e o notebook não consegue ingressar nele, inicie o cliente com credenciais explícitas em vez da identidade da sessão da área de trabalho.

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

O interruptor /netonly guarda essas credenciais apenas para autenticação remota. Confirme o que o servidor realmente recebeu com SELECT SUSER_SNAME() em vez de confiar na caixa de conexão. Relata-se que guardar a credencial do endereço do servidor no Windows Credential Manager funciona para o SSMS, mas nem sempre para um serviço executado em outra conta, então verifique qual identidade o processo usa antes de mudar o login.

A latência transforma um cursor do lado do servidor em tempo limite

Um cursor do lado do servidor pede ao banco que retenha o resultado e o busque de forma incremental, o que transforma um resultado grande em muitas idas e voltas pequenas. Em uma LAN isso é barato. Por um túnel com dezenas de milissegundos de latência adicionada, a mesma consulta pode exceder o tempo limite do comando sem transferir quase nada.

Mude para um cursor do lado do cliente, ou aumente o tamanho da busca e agrupe as linhas, e o número de idas e voltas cai. O gargalo é o número de trocas, não a velocidade nominal do link, então medir a vazão vai enganá-lo enquanto medir as idas e voltas não. Teste com o maior conjunto de resultados que seus usuários realmente puxam, não com uma consulta de uma linha que retorna na hora. Se o tempo limite se desloca mas não desaparece, aumente juntos o tempo limite do comando e o tamanho da busca e meça de novo.

A mesma aritmética vale para ORMs faladores e para qualquer cliente que emite uma instrução por linha. Se o plano da consulta está bom e a transferência é pequena, conte as trocas de rede antes de ajustar o banco.

Verifique a porta, a instância e o filtro local

Uma instância nomeada escuta em uma porta dinâmica, então confirme a porta em vez de presumir 1433. Em uma instância padrão o valor pode ser lido do valor de registro TcpPort sob a chave SuperSocketNetLib da instância. Para Oracle, verifique se o host em tnsnames.ora resolve, se o endereço responde e se a porta do listener é permitida; 1521 é um padrão comum, não uma garantia.

Depois descarte a lista de acesso do próprio túnel e, por fim, um antivírus local ou firewall de host que bloqueia a conexão mesmo quando cliente e servidor estão na mesma máquina. Registre o estágio que falha antes de mudar a configuração, porque resolução de nomes, alcance TCP e TLS ou login falham cada um com uma mensagem diferente.

Escreva o estágio no ticket. Caso contrário, a próxima pessoa repetirá a mesma busca por cadeia de conexão que começou tudo.