MySQL localhost su VPN: significa ancora il processo locale

L’applicazione sul server dell’ufficio si connette a MySQL su localhost, copi quel nome host in un client desktop e la connessione fallisce o apre un altro database. La VPN non ha cambiato il significato della parola: localhost indica ancora la macchina che esegue il client. La VPN ha spostato pacchetti, non interfacce. Decidi quale endpoint deve raggiungere il portatile prima di toccare una rotta.

Passo 1: decidi quale endpoint deve raggiungere il portatile

Entrambi i progetti sono legittimi e rispondono a domande diverse. L’accesso diretto significa che il database ascolta su un indirizzo privato che il tunnel raggiunge, e il portatile si connette a quell’indirizzo. L’accesso inoltrato significa che il database resta su loopback e una sessione SSH porta la porta alla tua macchina. Scegline uno deliberatamente, perché mescolarli produce una connessione che funziona per il motivo sbagliato.

Per l’accesso diretto, ottieni il nome o l’indirizzo privato proprio dell’host del database e la sua porta da chi lo gestisce. L’indirizzo del gateway VPN non è l’indirizzo del database a meno che non sia la stessa macchina. Poi conferma che il listener sia davvero legato a quell’interfaccia, perché una rotta verso un’interfaccia non crea un listener su di essa.

Passo 2: inoltra la porta solo se il listener resta locale

Se il database deve restare solo su loopback, inoltralo tramite SSH e lega anche l’estremità locale a loopback. L’indirizzo di bind a sinistra appartiene al tuo portatile; la destinazione a destra viene interpretata dal lato del server SSH, come descrive la documentazione di OpenSSH. Invertire questi due ruoli è il motivo abituale per cui un inoltro sembra funzionare ma non si connette a nulla.

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

Se SSH atterra su un host di salto invece che sull’host del database, il loopback a destra si riferisce all’host di salto, e la destinazione deve cambiare in un indirizzo che quell’host raggiunge. ExitOnForwardFailure intercetta un fallimento nello stabilire l’inoltro, ma non dimostra che le connessioni successive alla destinazione riescano. Tieni attivo il controllo della chiave dell’host e non offrire la porta di inoltro a tutta la tua LAN legandola a tutte le interfacce.

Fermati se il database deve restare solo su loopback e non puoi usare SSH. Allora l’accesso diretto è il progetto sbagliato, non una configurazione da forzare.

Passo 3: forza il client su TCP

Su Unix, un client MySQL a cui viene dato localhost sceglie un socket Unix per impostazione predefinita, quindi cambiare solo la porta può lasciarlo a cercare un socket che non ha nulla a che fare con il tuo inoltro. Usa il protocollo TCP esplicito e l’indirizzo loopback per far aprire al client una connessione alla tua porta di inoltro.

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

L’opzione password senza valore chiede invece di mettere il segreto nella riga di comando, ed è l’abitudine che vale la pena mantenere. Altri strumenti hanno il proprio interruttore per la stessa distinzione, e alcuni driver trattano localhost in modo speciale. Controlla cosa fa il tuo client invece di dare per scontato che il flag sia passato. L’account del database ha bisogno anche di un permesso che corrisponda all’origine che il server vede, cioè l’host di inoltro e non il tuo portatile.

Fermati se lo strumento non può essere forzato su TCP. Allora usa un altro client, oppure l’accesso diretto al listener privato.

Passo 4: dimostra quale endpoint hai raggiunto davvero

Chiedi al server cosa pensa che sia la connessione. Le variabili di nome host, porta e socket ti dicono se sei arrivato via TCP e quale listener ha risposto, e l’elenco delle connessioni mostra l’indirizzo di origine che il server ha registrato. Quella prova è più utile di un altro cambio di rotta.

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

Annota quale endpoint hai tentato: un socket Unix locale, la tua porta di inoltro o il listener privato. Quei tre fallimenti hanno correzioni diverse, e cambiare la rotta della VPN mentre il client parla ancora con il localhost sbagliato è fatica sprecata. Tieni separate nelle note anche l’autenticazione SSH e l’autenticazione del database, perché un fallimento in una sembra un fallimento nell’altra da un client desktop. Poi rimuovi l’inoltro quando hai finito.

L’elenco finisce quando sai nominare l’endpoint, il protocollo del client, l’indirizzo di origine che il server ha visto e il permesso che lo ha consentito. Quattro fatti, e il prossimo problema di connessione richiede minuti invece di un pomeriggio.