MariaDB su VPN: quale user@host vede il server?

Digita lo stesso nome utente da due percorsi diversi e MariaDB può autenticarti come due account diversi. Gli account sono indicizzati su utente e host insieme, quindi 'reporter'@'localhost' e 'reporter'@'10.90.0.23' sono righe separate con password separate e permessi separati. Su una VPN, la domanda interessante non è quale nome abbia digitato l’utente, ma quale indirizzo di origine il server ha visto.

Determina l’origine che il server vede davvero

Lavora a ritroso dall’host del database, non dal portatile. L’indirizzo che il client crede di avere è solo una delle varie possibilità:

Usa prove lato server per risolverlo. Un log delle connessioni, un elenco di sessioni attive o una voce temporanea nel log generale mostrano l’indirizzo che il server ha accettato. L’IP pubblico del portatile visto da un browser è un fatto diverso e spesso fuorviante.

Abbina l’account che MariaDB ha selezionato

La selezione dell’account segue un ordine documentato e non un’unione di permessi. Una corrispondenza esatta dell’host ha la precedenza su un carattere jolly, e le righe di utente anonimo partecipano alla corrispondenza in modi che sorprendono chi presume che decida solo il nome. Il server sceglie una riga; non fonde i privilegi di ogni riga con lo stesso nome. Leggere il riferimento una volta vale più di un pomeriggio di tentativi.

Ciò significa che aggiungere un permesso a 'reporter'@'%' può non cambiare nulla se la sessione si è autenticata come 'reporter'@'10.90.0.23'. La correzione deve cadere sulla riga che è stata selezionata, per questo identificare l’account precede la modifica dei permessi.

Leggi l’account che la sessione usa davvero

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

CURRENT_USER() indica l’account che ha autenticato la sessione; USER() riporta ciò che il client ha richiesto e può differire. Eseguile come normali query di primo livello, non dall’interno di una routine memorizzata con contesto di definer, altrimenti le risposte descrivono il proprietario della routine invece della tua sessione.

Un accesso fallito non può eseguire nulla di tutto ciò, ed è il caso in cui un amministratore deve invece ispezionare le definizioni degli account e le prove di connessione del server. Pianificalo: chi esegue il debug di un accesso rifiutato di solito non ha alcuna sessione SQL da interrogare.

Separa la raggiungibilità dall’autenticazione

Il testo dell’errore ti dice in quale livello sei. Una connessione rifiutata o un timeout significa che il client non ha mai raggiunto un listener, quindi l’account e la sua password non sono ancora in discussione. Una risposta di accesso negato significa che il server ha risposto, il che dimostra la raggiungibilità e punta all’account, alla corrispondenza dell’host o alla credenziale.

I prerequisiti di rete sono una lista a sé: un listener legato all’indirizzo previsto e non solo al loopback, traffico consentito verso la porta configurata e una rotta di ritorno per la risposta. Ognuno può fallire in modo indipendente, e un tunnel funzionante non ne implica nessuno. Un listener sul loopback accetta connessioni locali e rifiuta ogni connessione remota, il che produce una connessione rifiutata che sembra un blocco del firewall.

Controlla l’indirizzo di binding prima di aprire un ticket al team di rete. ss -lntp sull’host del database mostra quale indirizzo e quale porta stanno davvero ascoltando, e quella singola riga esclude un’intera categoria di ipotesi.

Ripara in modo mirato, poi ritesta entrambe le direzioni

Crea l’account previsto qualificato per host tramite il processo approvato dell’organizzazione, con una credenziale dello store supportato anziché una condivisa incollata in un ticket. Concedi solo le operazioni di schema necessarie al compito. Trasformare un accesso remoto fallito in un account root, in una policy di concessione totale o in un host jolly generalizzato fa passare il test e rimuove il controllo che stavi testando. Il permesso aggiunto in fretta è quello che nessuno rimuove dopo.

Ritesta con una sessione nuova attraverso il percorso previsto, poi controlla i casi negativi. Un percorso che dovrebbe essere bloccato deve restare bloccato, e un’operazione non concessa deve restare negata. Questi due controlli sono ciò che distingue un account riparato da uno allargato.

Infine, annota insieme l’indirizzo di origine osservato e il nome dell’account. Il tunnel fornisce la raggiungibilità; MariaDB sceglie e autorizza ancora il proprio account, e la persona successiva ha bisogno di entrambi i fatti per riprodurre il tuo risultato.