MariaDB via un VPN : quel user@host le serveur voit-il ?

Saisissez le même nom d’utilisateur par deux chemins différents et MariaDB peut vous authentifier comme deux comptes différents. Les comptes sont indexés sur l’utilisateur et l’hôte ensemble, donc 'reporter'@'localhost' et 'reporter'@'10.90.0.23' sont des lignes distinctes avec des mots de passe distincts et des droits distincts. Via un VPN, la question intéressante n’est pas le nom saisi par l’utilisateur, mais quelle adresse source le serveur a observée.

Déterminez la source que le serveur voit réellement

Travaillez à rebours depuis l’hôte de la base de données, pas depuis le portable. L’adresse que le client croit avoir n’est qu’une possibilité parmi plusieurs :

Utilisez des preuves côté serveur pour trancher. Un journal de connexions, une liste de sessions actives ou une entrée temporaire dans le journal général montre l’adresse que le serveur a acceptée. L’IP publique du portable vue depuis un navigateur est un autre fait, souvent trompeur.

Faites correspondre le compte que MariaDB a sélectionné

La sélection du compte suit un ordre documenté et non une union de droits. Une correspondance exacte d’hôte prime sur un joker, et les lignes d’utilisateur anonyme participent à la correspondance d’une manière qui surprend ceux qui supposent que le nom seul décide. Le serveur choisit une ligne ; il ne fusionne pas les privilèges de chaque ligne de même nom. Lire la référence une fois vaut mieux qu’un après-midi de suppositions.

Cela signifie qu’ajouter un droit à 'reporter'@'%' peut ne rien changer si la session s’est authentifiée comme 'reporter'@'10.90.0.23'. La correction doit atterrir sur la ligne qui a été sélectionnée, c’est pourquoi identifier le compte précède la modification des droits.

Lisez le compte que la session utilise réellement

SELECT USER(), CURRENT_USER();
SHOW GRANTS;

CURRENT_USER() nomme le compte qui a authentifié la session ; USER() indique ce que le client a demandé et peut différer. Exécutez-les comme des requêtes ordinaires de premier niveau, pas depuis une routine stockée avec un contexte de définisseur, sinon les réponses décrivent le propriétaire de la routine au lieu de votre session.

Une connexion échouée ne peut rien exécuter de tout cela, et c’est le cas où un administrateur doit inspecter les définitions de comptes et les preuves de connexion du serveur. Prévoyez-le : la personne qui débogue une connexion refusée n’a généralement aucune session SQL à interroger.

Séparez l’accessibilité de l’authentification

Le texte de l’erreur vous dit dans quelle couche vous êtes. Une connexion refusée ou un délai dépassé signifie que le client n’a jamais atteint un écouteur, donc le compte et son mot de passe ne sont pas encore en cause. Une réponse d’accès refusé signifie que le serveur a répondu, ce qui prouve l’accessibilité et pointe vers le compte, la correspondance d’hôte ou le justificatif.

Les prérequis réseau forment leur propre liste : un écouteur lié à l’adresse prévue et pas seulement au loopback, du trafic autorisé vers le port configuré et une route de retour pour la réponse. Chacun peut échouer indépendamment, et un tunnel qui fonctionne n’en implique aucun. Un écouteur sur le loopback accepte les connexions locales et refuse toutes les distantes, ce qui produit une connexion refusée qui ressemble à un blocage de pare-feu.

Vérifiez l’adresse de liaison avant d’ouvrir un ticket à l’équipe réseau. ss -lntp sur l’hôte de la base de données montre quelle adresse et quel port écoutent réellement, et cette seule ligne écarte toute une catégorie de suppositions.

Réparez étroitement, puis retestez les deux sens

Créez le compte prévu qualifié par hôte via le processus approuvé de l’organisation, avec un justificatif du magasin pris en charge plutôt qu’un justificatif partagé collé dans un ticket. N’accordez que les opérations de schéma dont la tâche a besoin. Transformer une connexion distante échouée en compte root, en politique d’accord total ou en hôte joker général fait passer le test et supprime le contrôle que vous testiez. Le droit ajouté dans la hâte est celui que personne ne retire ensuite.

Retestez avec une session neuve par le chemin prévu, puis vérifiez les cas négatifs. Un chemin qui devrait être bloqué doit rester bloqué, et une opération non accordée doit rester refusée. Ces deux vérifications séparent un compte réparé d’un compte élargi.

Enfin, consignez ensemble l’adresse source observée et le nom du compte. Le tunnel fournit l’accessibilité ; MariaDB choisit et autorise toujours son propre compte, et la personne suivante a besoin des deux faits pour reproduire votre résultat.