MySQL localhost por VPN: segue a significar o proceso local

A aplicación do servidor de oficina conéctase a MySQL en localhost, copias ese nome de host nun cliente de escritorio e a conexión ou falla ou abre outra base de datos. A VPN non cambiou o significado da palabra: localhost segue referíndose á máquina que executa o cliente. A VPN moveu paquetes, non interfaces. Decide a que extremo debe chegar o portátil antes de tocar unha ruta.

Paso 1: decide a que extremo debe chegar o portátil

Os dous deseños son lexítimos e responden preguntas distintas. O acceso directo significa que a base de datos escoita nun enderezo privado que o túnel alcanza, e o portátil conéctase a ese enderezo. O acceso reenviado significa que a base de datos queda en loopback e unha sesión SSH leva o porto ata a túa máquina. Escolle un a propósito, porque mesturalos produce unha conexión que funciona polo motivo equivocado.

Para o acceso directo, obtén o nome ou o enderezo privado propio do host da base de datos e o seu porto de quen a administra. O enderezo da pasarela VPN non é o enderezo da base de datos agás que sexa a mesma máquina. Despois confirma que o oínte está realmente ligado a esa interface, porque unha ruta cara a unha interface non crea un oínte nela.

Paso 2: reenvía o porto só se o oínte queda local

Se a base de datos debe quedar só en loopback, reenvíaa por SSH e liga tamén o extremo local a loopback. O enderezo de enlace da esquerda pertence ao teu portátil; o destino da dereita interprétase desde o lado do servidor SSH, como describe a referencia de OpenSSH. Inverter eses dous papeis é o motivo habitual de que un reenvío pareza funcionar pero non conecte con nada.

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

Se SSH aterra nun host de salto en lugar do host da base de datos, o loopback da dereita refírese ao host de salto, e o destino ten que cambiar a un enderezo que ese host alcance. ExitOnForwardFailure detecta un fallo ao establecer o reenvío, pero non demostra que as conexións posteriores ao destino teñan éxito. Mantén activa a comprobación da clave de host e non ofrezas o porto de reenvío a toda a túa LAN ligándoo a todas as interfaces.

Detente se a base de datos debe quedar só en loopback e non podes usar SSH. Entón o acceso directo é o deseño equivocado, non unha configuración que forzar.

Paso 3: forza o cliente a TCP

En Unix, un cliente de MySQL ao que se lle dá localhost escolle un socket Unix por defecto, así que cambiar só o porto pode deixalo buscando un socket que non ten nada que ver co teu reenvío. Usa o protocolo TCP explícito e o enderezo loopback para que o cliente abra unha conexión ao teu porto de reenvío.

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

A opción de contrasinal sen valor pregunta en lugar de poñer o segredo na liña de ordes, e ese é o costume que paga a pena manter. Outras ferramentas teñen o seu propio interruptor para a mesma distinción, e algúns controladores tamén tratan localhost de forma especial. Comproba que fai o teu cliente en lugar de supoñer que o indicador se mantivo. A conta da base de datos tamén necesita un permiso que coincida coa orixe que ve o servidor, que é o host de reenvío e non o teu portátil.

Detente se a ferramenta non se pode forzar a TCP. Entón usa outro cliente ou o acceso directo ao oínte privado.

Paso 4: demostra a que extremo chegaches realmente

Pregúntalle ao servidor que cre que é a conexión. As variables de nome de host, porto e socket dinche se chegaches por TCP e que oínte respondeu, e a lista de conexións mostra o enderezo de orixe que rexistrou o servidor. Esa evidencia é máis útil que outro cambio de ruta.

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

Anota a que extremo intentaches chegar: un socket Unix local, o teu porto de reenvío ou o oínte privado. Eses tres fallos teñen arranxos distintos, e cambiar a ruta da VPN mentres o cliente aínda fala co localhost equivocado é esforzo perdido. Mantén tamén separadas nas notas a autenticación SSH e a autenticación da base de datos, porque un fallo nunha parece un fallo na outra desde un cliente de escritorio. Despois quita o reenvío cando remates.

A lista remata cando podes nomear o extremo, o protocolo do cliente, o enderezo de orixe que viu o servidor e o permiso que o permitiu. Catro feitos, e o seguinte problema de conexión tarda minutos en lugar dunha tarde.