MySQL localhost per VPN: segueix significant el procés local

L’aplicació del servidor d’oficina es connecta a MySQL a localhost, copieu aquest nom d’amfitrió en un client d’escriptori i la connexió o falla o obre una altra base de dades. La VPN no ha canviat el significat de la paraula: localhost encara fa referència a la màquina que executa el client. La VPN ha mogut paquets, no interfícies. Decidiu a quin extrem ha d’arribar el portàtil abans de tocar cap ruta.

Pas 1: decidiu a quin extrem ha d’arribar el portàtil

Els dos dissenys són legítims i responen preguntes diferents. L’accés directe vol dir que la base de dades escolta en una adreça privada que el túnel pot assolir, i el portàtil es connecta a aquesta adreça. L’accés reenviat vol dir que la base de dades es queda a loopback i una sessió SSH porta el port fins a la vostra màquina. Trieu-ne un deliberadament, perquè barrejar-los produeix una connexió que funciona pel motiu equivocat.

Per a l’accés directe, obteniu el nom o l’adreça privada pròpia de l’amfitrió de la base de dades i el seu port de qui la gestiona. L’adreça de la passarel·la VPN no és l’adreça de la base de dades tret que sigui la mateixa màquina. Després confirmeu que l’oient està realment lligat a aquesta interfície, perquè una ruta cap a una interfície no crea cap oient en ella.

Pas 2: reenvieu el port només si l’oient es queda local

Si la base de dades ha de quedar només a loopback, reenvieu-la per SSH i lligueu també l’extrem local a loopback. L’adreça d’enllaç de l’esquerra pertany al vostre portàtil; l’objectiu de la dreta s’interpreta des del costat del servidor SSH, tal com descriu la referència d’OpenSSH. Invertir aquests dos papers és el motiu habitual que un reenviament sembli funcionar però no es connecti enlloc.

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

Si l’SSH acaba en un amfitrió de salt en lloc de l’amfitrió de la base de dades, el loopback de la dreta fa referència a l’amfitrió de salt, i l’objectiu ha de canviar a una adreça que aquest amfitrió pugui assolir. ExitOnForwardFailure detecta un fracàs a establir el reenviament, però no demostra que les connexions posteriors a l’objectiu tinguin èxit. Manteniu la verificació de la clau d’amfitrió activada i no oferiu el port de reenviament a tota la vostra LAN lligant-lo a totes les interfícies.

Atureu-vos si la base de dades ha de quedar només a loopback i no podeu fer servir SSH. L’accés directe és llavors el disseny equivocat, no una configuració a forçar.

Pas 3: forceu el client a TCP

A Unix, un client MySQL al qual es dóna localhost tria un sòcol Unix per defecte, així que canviar només el port pot deixar-lo buscant un sòcol que no té res a veure amb el vostre reenviament. Feu servir el protocol TCP explícit i l’adreça loopback perquè el client obri una connexió al vostre port de reenviament.

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

L’opció de contrasenya sense valor pregunta en lloc de posar el secret a la línia d’ordres, i és el costum que val la pena mantenir. Altres eines tenen el seu propi commutador per a la mateixa distinció, i alguns controladors també tracten localhost d’una manera especial. Comproveu què fa el vostre client en lloc d’assumir que el senyal s’ha mantingut. El compte de la base de dades també necessita un permís que coincideixi amb l’origen que veu el servidor, que és l’amfitrió de reenviament i no el vostre portàtil.

Atureu-vos si l’eina no es pot forçar a TCP. Llavors feu servir un altre client, o bé l’accés directe a l’oient privat.

Pas 4: demostreu a quin extrem heu arribat realment

Pregunteu al servidor què creu que és la connexió. Les variables de nom d’amfitrió, port i sòcol us diuen si heu arribat per TCP i quin oient ha respost, i la llista de connexions mostra l’adreça d’origen que el servidor ha registrat. Aquesta evidència és més útil que un altre canvi de ruta.

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

Anoteu a quin extrem heu intentat arribar: un sòcol Unix local, el vostre port de reenviament o l’oient privat. Aquests tres fracassos tenen arranjaments diferents, i canviar la ruta de la VPN mentre el client encara parla amb el localhost equivocat és esforç perdut. Manteniu també separades a les notes l’autenticació SSH i l’autenticació de la base de dades, perquè un fracàs en una sembla un fracàs en l’altra des d’un client d’escriptori. Després traieu el reenviament quan hàgiu acabat.

La llista s’acaba quan podeu anomenar l’extrem, el protocol del client, l’adreça d’origen que el servidor ha vist i el permís que ho ha permès. Quatre fets, i el proper problema de connexió es resol en minuts en lloc d’una tarda.