MariaDB por VPN: qual user@host o servidor vê?

Digite o mesmo nome de usuário por dois caminhos diferentes e o MariaDB pode autenticar você como duas contas diferentes. As contas são indexadas por usuário e host juntos, então 'reporter'@'localhost' e 'reporter'@'10.90.0.23' são linhas separadas com senhas separadas e permissões separadas. Por VPN, a pergunta interessante não é qual nome o usuário digitou, mas qual endereço de origem o servidor viu.

Determine a origem que o servidor realmente vê

Trabalhe de trás para frente a partir do host do banco de dados, não do notebook. O endereço que o cliente pensa ter é apenas uma entre várias possibilidades:

Use evidências do lado do servidor para decidir. Um log de conexões, uma lista de sessões ativas ou uma entrada temporária no log geral mostram o endereço que o servidor aceitou. O IP público do notebook visto de um navegador é outro fato e muitas vezes enganoso.

Combine a conta que o MariaDB selecionou

A seleção de conta segue uma ordem documentada e não uma união de permissões. Uma correspondência exata de host tem precedência sobre um curinga, e linhas de usuário anônimo participam da correspondência de formas que surpreendem quem assume que só o nome decide. O servidor escolhe uma linha; ele não funde os privilégios de cada linha com o mesmo nome. Ler a referência uma vez vale mais que uma tarde testando suposições.

Isso significa que adicionar uma permissão a 'reporter'@'%' pode não mudar nada se a sessão se autenticou como 'reporter'@'10.90.0.23'. A correção precisa cair na linha que foi selecionada, por isso identificar a conta vem antes de editar permissões.

Leia a conta que a sessão realmente usa

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

CURRENT_USER() nomeia a conta que autenticou a sessão; USER() informa o que o cliente pediu e pode diferir. Execute-as como consultas normais de nível superior, não de dentro de uma rotina armazenada com contexto de definidor, senão as respostas descrevem o dono da rotina em vez da sua sessão.

Um login malsucedido não consegue executar nada disso, e é o caso em que um administrador precisa inspecionar as definições de conta e as evidências de conexão do servidor. Planeje isso: quem depura um login rejeitado normalmente não tem sessão SQL para consultar.

Separe a alcançabilidade da autenticação

O texto do erro diz em que camada você está. Uma conexão recusada ou um tempo esgotado significa que o cliente nunca chegou a um ouvinte, então a conta e a senha ainda não estão em questão. Uma resposta de acesso negado significa que o servidor respondeu, o que prova alcançabilidade e aponta para a conta, a correspondência de host ou a credencial.

Os pré-requisitos de rede são uma lista própria: um ouvinte vinculado ao endereço pretendido e não apenas ao loopback, tráfego permitido para a porta configurada e uma rota de retorno para a resposta. Cada um pode falhar de forma independente, e um túnel funcional não implica nenhum deles. Um ouvinte no loopback aceita conexões locais e recusa todas as remotas, o que produz uma conexão recusada que parece um bloqueio de firewall.

Verifique o endereço de vinculação antes de abrir um ticket com a equipe de rede. ss -lntp no host do banco de dados mostra qual endereço e porta estão realmente ouvindo, e essa única linha descarta toda uma categoria de suposições.

Repare de forma estreita e depois teste os dois sentidos

Crie a conta pretendida qualificada por host pelo processo aprovado da organização, com uma credencial do armazenamento suportado e não uma compartilhada colada em um ticket. Conceda apenas as operações de esquema de que a tarefa precisa. Transformar um login remoto malsucedido em conta root, política de conceder tudo ou host curinga abrangente faz o teste passar e remove o controle que você estava testando. A permissão adicionada às pressas é a que ninguém remove depois.

Teste novamente com uma sessão nova pelo caminho pretendido e depois verifique os casos negativos. Um caminho que deveria estar bloqueado deve continuar bloqueado, e uma operação que não foi concedida deve continuar negada. Essas duas verificações são o que separa uma conta reparada de uma ampliada.

Por fim, registre o endereço de origem observado e o nome da conta juntos. O túnel fornece alcançabilidade; o MariaDB continua escolhendo e autorizando a própria conta, e a próxima pessoa precisa dos dois fatos para reproduzir o seu resultado.