MySQL localhost über ein VPN: es bleibt der lokale Prozess

Die Anwendung auf dem Büroserver verbindet sich mit MySQL unter localhost, Sie kopieren diesen Hostnamen in einen Desktop-Client, und die Verbindung schlägt entweder fehl oder öffnet eine andere Datenbank. Am Wort hat das VPN nichts geändert: localhost bezeichnet weiterhin den Rechner, auf dem der Client läuft. Das VPN hat Pakete bewegt, keine Schnittstellen. Entscheiden Sie, welchen Endpunkt der Laptop erreichen soll, bevor Sie eine Route anfassen.

Schritt 1: entscheiden Sie, welchen Endpunkt der Laptop erreichen soll

Beide Entwürfe sind legitim und beantworten verschiedene Fragen. Direkter Zugriff bedeutet, dass die Datenbank auf einer privaten Adresse lauscht, die der Tunnel erreicht, und der Laptop sich mit dieser Adresse verbindet. Weitergeleiteter Zugriff bedeutet, dass die Datenbank auf loopback bleibt und eine SSH-Sitzung den Port zu Ihrem Rechner trägt. Wählen Sie bewusst einen, denn die Mischung ergibt eine Verbindung, die aus dem falschen Grund funktioniert.

Für den direkten Zugriff holen Sie sich den eigenen privaten Namen oder die Adresse des Datenbank-Hosts und seinen Port bei dem, der ihn betreibt. Die Adresse des VPN-Gateways ist nicht die Datenbankadresse, außer es ist derselbe Rechner. Bestätigen Sie dann, dass der Listener wirklich an diese Schnittstelle gebunden ist, denn eine Route zu einer Schnittstelle erzeugt dort keinen Listener.

Schritt 2: leiten Sie den Port nur weiter, wenn der Listener lokal bleibt

Soll die Datenbank nur auf loopback bleiben, leiten Sie sie über SSH weiter und binden auch das lokale Ende an loopback. Die Bindeadresse links gehört zu Ihrem Laptop; das Ziel rechts wird aus Sicht des SSH-Servers gelesen, wie die OpenSSH-Referenz beschreibt. Diese beiden Rollen zu vertauschen ist der übliche Grund, warum eine Weiterleitung zu funktionieren scheint, aber mit nichts verbindet.

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

Landet SSH auf einem Sprunghost statt auf dem Datenbank-Host, bezieht sich das loopback rechts auf den Sprunghost, und das Ziel muss auf eine Adresse wechseln, die dieser Host erreicht. ExitOnForwardFailure fängt ein Scheitern beim Aufbau der Weiterleitung ab, beweist aber nicht, dass spätere Verbindungen zum Ziel gelingen. Lassen Sie die Hostschlüsselprüfung an und bieten Sie den Weiterleitungsport nicht Ihrem ganzen LAN an, indem Sie ihn an alle Schnittstellen binden.

Halten Sie an, wenn die Datenbank nur auf loopback bleiben muss und Sie SSH nicht nutzen können. Dann ist der direkte Zugriff der falsche Entwurf, keine Konfiguration, die man erzwingt.

Schritt 3: zwingen Sie den Client auf TCP

Unter Unix wählt ein MySQL-Client mit localhost standardmäßig einen Unix-Socket, sodass eine reine Portänderung ihn nach einem Socket suchen lässt, der mit Ihrer Weiterleitung nichts zu tun hat. Nutzen Sie das ausdrückliche TCP-Protokoll und die loopback-Adresse, damit der Client eine Verbindung zu Ihrem Weiterleitungsport öffnet.

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

Die Passwortoption ohne Wert fragt nach, statt das Geheimnis in die Kommandozeile zu schreiben, und das ist die Gewohnheit, die man behalten sollte. Andere Werkzeuge haben ihren eigenen Schalter für dieselbe Unterscheidung, und manche Treiber behandeln localhost ebenfalls besonders. Prüfen Sie, was Ihr Client tut, statt anzunehmen, das Flag sei mitgekommen. Das Datenbankkonto braucht außerdem eine Berechtigung, die zur Quelle passt, die der Server sieht, und das ist der Weiterleitungshost, nicht Ihr Laptop.

Halten Sie an, wenn das Werkzeug nicht auf TCP gezwungen werden kann. Nutzen Sie dann einen anderen Client oder den direkten Zugriff auf den privaten Listener.

Schritt 4: beweisen Sie, welchen Endpunkt Sie tatsächlich erreicht haben

Fragen Sie den Server, wofür er die Verbindung hält. Die Variablen für Hostname, Port und Socket sagen Ihnen, ob Sie über TCP kamen und welcher Listener geantwortet hat, und die Verbindungsliste zeigt die Quelladresse, die der Server aufgezeichnet hat. Dieser Beleg ist nützlicher als eine weitere Routenänderung.

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

Notieren Sie, welchen Endpunkt Sie versucht haben: einen lokalen Unix-Socket, Ihren Weiterleitungsport oder den privaten Listener. Diese drei Fehler haben verschiedene Lösungen, und die VPN-Route zu ändern, während der Client noch mit dem falschen localhost spricht, ist verschwendete Mühe. Halten Sie in den Notizen auch SSH-Authentifizierung und Datenbank-Authentifizierung getrennt, denn ein Fehler in der einen sieht aus einem Desktop-Client wie ein Fehler in der anderen aus. Entfernen Sie die Weiterleitung dann, wenn Sie fertig sind.

Die Checkliste endet, wenn Sie den Endpunkt, das Client-Protokoll, die Quelladresse, die der Server sah, und die Berechtigung, die es erlaubte, benennen können. Vier Fakten, und das nächste Verbindungsproblem dauert Minuten statt eines Nachmittags.