Non, une chaîne de connexion ne peut pas démarrer votre tunnel VPN

Les développeurs continuent de chercher l'endroit où une chaîne de connexion, une URL JDBC ou une entrée tnsnames.ora sélectionne le VPN. Cet endroit n'existe pas. Le tunnel est établi par le système d'exploitation ou par un client de l'éditeur qui enregistre une carte réseau virtuelle, et chaque bibliothèque de base de données au-dessus utilise la couche socket qui en résulte. Une chaîne de connexion nomme un hôte, un port et un identifiant, et c'est tout le vocabulaire.

Mythe : la chaîne de connexion peut sélectionner un tunnel

Le pilote ouvre un socket TCP vers un hôte et un port. Il n'a pas d'API pour monter un tunnel, pas de champ pour un profil de tunnel et aucun moyen de s'authentifier auprès d'une passerelle VPN.

C'est pourquoi les outils se comportent de façon identique dès qu'une route existe. SSMS, DBeaver, Eclipse Data Tools et un simple sqlcmd agissent comme si le serveur était sur le réseau local, car du point de vue du socket il l'est. La carte virtuelle a rendu le sous-réseau de la base accessible, et le pilote ne sait jamais comment.

Cela explique aussi pourquoi une chaîne de connexion ne peut pas réparer un tunnel tombé. Quand la liaison meurt, le pilote signale un délai d'attente ou une erreur réseau générale, et le code applicatif qui traite cela comme un problème de requête réessaie indéfiniment la mauvaise couche.

Montez le tunnel avant que le pilote ne s'exécute

Connectez le VPN au niveau du système d'exploitation, en suivant les instructions du fournisseur ou de l'équipe réseau, et n'ouvrez l'outil qu'ensuite. En pratique, cela signifie qu'une route vers le sous-réseau de la base existe avant que le pilote ne résolve le nom d'hôte.

Gardez la supervision du tunnel hors de l'application. Un service PHP ou Java qui tente de monter lui-même la liaison encode le comportement d'un fournisseur dans le code métier, et chaque basculement devient une livraison d'application. Un superviseur qui possède le tunnel, le surveille et le redémarre est un sujet distinct du chemin de requête.

Vérifiez la route avant d'accuser le pilote: si l'hôte ne se résout pas ou si le port ne répond pas depuis le shell, aucune chaîne de connexion ne changera cela.

Mythe : un échec d'authentification Windows signifie que la route est cassée

L'authentification Windows à travers un VPN échoue souvent avec une erreur qui ressemble à une panne réseau, alors que la route est bonne. Lorsque le compte appartient à un autre domaine et que le portable ne peut pas le rejoindre, démarrez le client avec des identifiants explicites plutôt qu'avec l'identité de la session de bureau.

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

Le commutateur /netonly ne conserve ces identifiants que pour l'authentification distante. Confirmez ce que le serveur a réellement reçu avec SELECT SUSER_SNAME() au lieu de faire confiance à la boîte de dialogue de connexion. Il est rapporté que stocker l'identifiant de l'adresse du serveur dans Windows Credential Manager fonctionne pour SSMS mais pas toujours pour un service exécuté sous un autre compte, vérifiez donc quelle identité le processus utilise avant de changer la connexion.

La latence transforme un curseur côté serveur en délai d'attente

Un curseur côté serveur demande à la base de garder le résultat et de le récupérer progressivement, ce qui transforme un gros résultat en nombreux petits allers-retours. Sur un LAN, c'est bon marché. À travers un tunnel ajoutant des dizaines de millisecondes de latence, la même requête peut dépasser le délai d'attente de la commande sans presque rien transférer.

Passez à un curseur côté client, ou augmentez la taille de récupération et lotissez les lignes, et le nombre d'allers-retours chute. Le goulot d'étranglement est le nombre d'échanges, pas le débit nominal de la liaison, donc mesurer le débit vous induira en erreur alors que mesurer les allers-retours non. Testez avec le plus gros jeu de résultats que vos utilisateurs tirent réellement, pas avec une requête d'une ligne qui revient instantanément. Si le délai d'attente se déplace mais ne disparaît pas, augmentez ensemble le délai d'attente de la commande et la taille de récupération, puis mesurez de nouveau.

La même arithmétique s'applique aux ORM bavards et à tout client qui émet une instruction par ligne. Si le plan de requête est bon et le transfert faible, comptez les échanges réseau avant de régler la base.

Vérifiez le port, l'instance et le filtre local

Une instance nommée écoute sur un port dynamique, alors confirmez le port au lieu de supposer 1433. Sur une instance par défaut, la valeur se lit dans la valeur de registre TcpPort sous la clé SuperSocketNetLib de l'instance. Pour Oracle, vérifiez que l'hôte de tnsnames.ora se résout, que l'adresse répond et que le port d'écoute est autorisé ; 1521 est une valeur par défaut courante, pas une garantie.

Écartez ensuite la liste d'accès du tunnel lui-même et, enfin, un antivirus local ou un pare-feu d'hôte qui bloque la connexion même lorsque client et serveur sont sur la même machine. Capturez l'étape qui échoue avant de changer la configuration, car la résolution de noms, la joignabilité TCP et TLS ou la connexion échouent chacun avec un message différent.

Écrivez l'étape dans le ticket. Sinon, la personne suivante refera la même recherche de chaîne de connexion qui a tout déclenché.