MySQL localhost via un VPN : cela reste le processus local

L’application du serveur de bureau se connecte à MySQL sur localhost, vous copiez ce nom d’hôte dans un client de bureau, et la connexion échoue ou ouvre une autre base de données. Le VPN n’a rien changé au sens du mot : localhost désigne toujours la machine qui exécute le client. Le VPN a déplacé des paquets, pas des interfaces. Décidez quel point de terminaison le portable doit atteindre avant de toucher à une route.

Étape 1 : décidez quel point de terminaison le portable doit atteindre

Les deux conceptions sont légitimes et répondent à des questions différentes. L’accès direct signifie que la base écoute sur une adresse privée que le tunnel atteint, et le portable se connecte à cette adresse. L’accès transféré signifie que la base reste sur loopback et qu’une session SSH porte le port jusqu’à votre machine. Choisissez l’un délibérément, car les mélanger produit une connexion qui fonctionne pour la mauvaise raison.

Pour l’accès direct, obtenez le nom ou l’adresse privée propres à l’hôte de la base et son port auprès de qui l’exploite. L’adresse de la passerelle VPN n’est pas l’adresse de la base, sauf s’il s’agit de la même machine. Vérifiez ensuite que l’écouteur est réellement lié à cette interface, car une route vers une interface n’y crée pas d’écouteur.

Étape 2 : ne transférez le port que si l’écouteur reste local

Si la base doit rester uniquement sur loopback, transférez-la par SSH et liez aussi l’extrémité locale à loopback. L’adresse de liaison de gauche appartient à votre portable ; la cible de droite est interprétée du côté du serveur SSH, comme le décrit la référence OpenSSH. Inverser ces deux rôles est la raison habituelle pour laquelle un transfert semble fonctionner mais ne se connecte à rien.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:13306:127.0.0.1:3306 [email protected]
ss -ltn 'sport = :13306'

Si SSH atterrit sur un hôte de rebond plutôt que sur l’hôte de la base, le loopback de droite désigne l’hôte de rebond, et la cible doit changer pour une adresse que cet hôte atteint. ExitOnForwardFailure intercepte un échec d’établissement du transfert, mais ne prouve pas que les connexions ultérieures à la cible réussissent. Gardez la vérification de clé d’hôte activée et n’offrez pas le port de transfert à tout votre LAN en le liant à toutes les interfaces.

Arrêtez si la base doit rester uniquement sur loopback et que vous ne pouvez pas utiliser SSH. L’accès direct est alors la mauvaise conception, pas une configuration à forcer.

Étape 3 : forcez le client sur TCP

Sous Unix, un client MySQL à qui l’on donne localhost choisit une socket Unix par défaut, donc changer seulement le port peut le laisser chercher une socket qui n’a rien à voir avec votre transfert. Utilisez le protocole TCP explicite et l’adresse loopback pour que le client ouvre une connexion vers votre port de transfert.

mysql --protocol=TCP --host=127.0.0.1 --port=13306 --user=DB_USER --password

L’option de mot de passe sans valeur demande au lieu de mettre le secret dans la ligne de commande, et c’est l’habitude qu’il vaut la peine de garder. D’autres outils ont leur propre commutateur pour la même distinction, et certains pilotes traitent aussi localhost à part. Vérifiez ce que fait votre client au lieu de supposer que l’option a été transmise. Le compte de la base a aussi besoin d’un droit qui corresponde à la source que le serveur voit, c’est-à-dire l’hôte de transfert et non votre portable.

Arrêtez si l’outil ne peut pas être forcé sur TCP. Utilisez alors un autre client, ou l’accès direct à l’écouteur privé.

Étape 4 : prouvez quel point de terminaison vous avez réellement atteint

Demandez au serveur ce qu’il croit que la connexion est. Les variables de nom d’hôte, de port et de socket vous disent si vous êtes arrivé par TCP et quel écouteur a répondu, et la liste des connexions montre l’adresse source que le serveur a enregistrée. Cette preuve est plus utile qu’un autre changement de route.

mysql --protocol=TCP -h 127.0.0.1 -P 13306 -u DB_USER -p -e "SELECT @@hostname, @@port, @@socket"

Notez quel point de terminaison vous avez tenté : une socket Unix locale, votre port de transfert ou l’écouteur privé. Ces trois échecs ont des correctifs différents, et changer la route du VPN alors que le client parle encore au mauvais localhost est un effort perdu. Gardez aussi l’authentification SSH et l’authentification de la base séparées dans les notes, car un échec dans l’une ressemble à un échec dans l’autre depuis un client de bureau. Retirez ensuite le transfert quand vous avez terminé.

La liste se termine quand vous pouvez nommer le point de terminaison, le protocole du client, l’adresse source que le serveur a vue et le droit qui l’a permis. Quatre faits, et le prochain problème de connexion prend des minutes au lieu d’un après-midi.