MySQL über ein VPN: Prüfen Sie den Server, nicht nur die Verschlüsselung
Verschlüsselung zum falschen Host bleibt falsch. Vergleichen Sie die ssl-mode-Werte und führen Sie dann eine Verbindung aus, die den gemeinten Server benennt und das belegt.
Sie speichern eine Verbindung zu 10.20.4.15, das VPN fällt aus, und der Client verbindet sich trotzdem. Das ist keine gute Nachricht. Eine private Adresse ist ein Ort innerhalb welchen Routing-Kontexts auch immer Sie sich befinden, und viele Netze verwenden dieselben Bereiche. Der Client erreichte einen MySQL-Server, nur vielleicht nicht Ihren.
Die Behebung hat zwei Hälften, und nur eine davon betrifft das Netzwerk. Halten Sie die Verbindung auf ihrem vorgesehenen Pfad und lassen Sie den Client den Server authentifizieren, mit dem er spricht. Die erste Hälfte ist die, bei der ein VPN hilft; die zweite muss konfiguriert werden.
Verschlüsselt wozu, genau?
TLS schützt das Gespräch vor jedem in der Mitte und sagt nichts darüber, wer der Endpunkt zu sein behauptet, es sei denn, der Client prüft es. Ein Zertifikat, das gegen eine vertrauenswürdige Stelle validiert, beweist, dass das Zertifikat von dieser Stelle stammt. Es beweist nicht, dass das Zertifikat für den Hostnamen ausgestellt wurde, den Sie erreichen wollten, und das sind verschiedene Fragen.
Das ist keine theoretische Lücke. Captive Portals, Fehler mit dem falschen VRF und überlappende Adresspläne erzeugen alle einen Server, der durchaus bereit ist, mit Ihnen TLS auszuhandeln. Wenn der Client nur Verschlüsselung verlangt, ist die Sitzung privat und auf die falsche Datenbank gerichtet.
Die relevante Frage ist also nicht, ob die Verbindung verschlüsselt ist, sondern ob sie zu der Identität verschlüsselt ist, die Sie beabsichtigt haben. Im MySQL-Client lebt dieser Unterschied vollständig in der Einstellung ssl-mode.
Die fünf ssl-mode-Werte in der Praxis
Es gibt fünf Werte, und nur einer von ihnen beantwortet die Frage dieses Runbooks. Die Tabelle listet auf, was jeder tatsächlich garantiert, statt was sein Name nahelegt.
| Mode | What it guarantees |
|---|---|
DISABLED | No TLS at all; everything on the wire is readable |
PREFERRED | Tries TLS and falls back to plaintext when the account and server allow it, so it is not a fail-closed requirement |
REQUIRED | Refuses to connect without TLS, and does not validate the certificate |
VERIFY_CA | Validates the server certificate against the configured CA and does not check the hostname |
VERIFY_IDENTITY | Validates the CA and checks that the certificate names the host the client used |
Nur die letzte Zeile beantwortet die Frage in diesem Artikel. PREFERRED ist für sich genommen erwähnenswert, weil ein Client, der still auf Klartext zurückfällt, schlimmer ist als einer, der ablehnt: Sie glauben, Sie hätten Verschlüsselung, und der Paketmitschnitt widerspricht.
Eine Verbindung, die Sie heute ausführen können
Der Befehl unten ist die Form, die Sie verwenden sollten, mit zwei Platzhaltern: dem genehmigten Datenbanknamen und einer CA-Datei, die über einen genehmigten Kanal bezogen wurde. Keines von beiden sollte aus dem genommen werden, was der Server Ihnen beim ersten Kontakt anbietet.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password ohne Wert fragt nach, was das Geheimnis aus der Prozessliste und aus Ihrer Shell-Historie heraushält. Das ist eine kleine Gewohnheit mit großem Nutzen auf gemeinsam genutzten Jump-Hosts, wo eine Befehlszeile für andere Benutzer sichtbar ist.
Wenn dies fehlschlägt, unterscheidet der Fehlertext die Fälle besser als die Intuition. Ein CA-Fehler bedeutet, dass die Kette nicht validiert, und Sie sollten prüfen, welche CA das Serverzertifikat signiert hat. Ein Hostnamen-Fehler bedeutet, dass die Kette in Ordnung ist und der Name nicht passt, was meist heißt, dass Sie den richtigen Server unter dem falschen Namen erreicht haben statt den falschen Server.
Dass eine Eingabeaufforderung erscheint, ist kein Beweis dafür, dass ein Passwort bereits übertragen wurde, und eine fehlgeschlagene Verbindung beweist nicht, dass nichts den Client verlassen hat. Wenn Sie ein vergangenes Ereignis rekonstruieren, identifizieren Sie den Client, seine Konfiguration, das Authentifizierungs-Plugin und die Phase, die fehlgeschlagen ist. Die Exposition aus der letzten Fehlermeldung zu schätzen ist Raten.
Wenn der Name aus einem Tunnel kommt
Lokale Portweiterleitung bricht die Identitätsprüfung auf eine Weise, die Menschen überrascht. Wenn Sie einen lokalen Port zur Datenbank weiterleiten und sich mit localhost verbinden, validiert der Client das Zertifikat gegen localhost, und für diesen Namen wurde kein Zertifikat ausgestellt. Die Verbindung kann völlig sicher sein, und die Prüfung wird trotzdem fehlschlagen, was die Prüfung ist, die wie vorgesehen arbeitet.
Es gibt zwei ehrliche Antworten. Geben Sie dem weitergeleiteten Endpunkt einen Namen, der auf die Loopback-Adresse auflöst und im Serverzertifikat erscheint, oder verwenden Sie den Hostnamen durchgängig, damit der Client die echte Identität prüft. Das erste ist für Entwickler bequem und erfordert Zertifikatsarbeit; das zweite ist leichter zu durchdenken und oft die richtige Voreinstellung für Automatisierung. Die Prüfung abzuschalten, damit die Weiterleitung funktioniert, wirft die Eigenschaft weg, die Sie hinzufügen wollten.
Abnahme sind drei Bedingungen
Schreiben Sie den Abnahmetest als drei getrennte Aussagen: Die Verbindung nutzte die vorgesehene Route, Verschlüsselung war erforderlich statt bevorzugt, und die Serveridentität wurde gegen vertrauenswürdiges Material geprüft. Ein grünes VPN-Symbol belegt keine davon.
Prüfen Sie bei GUI-Clients und bei MariaDB die eigene Dokumentation des Anbieters, statt anzunehmen, die Schreibweise des Flags werde übernommen. Die MySQL-Dokumentation zu verschlüsselten Verbindungen behandelt die Unterschiede der Modi und die Anforderung der CA-Verteilung, und sie ist die Referenz, die Sie prüfen sollten, bevor Sie eine Produktions-Verbindungszeichenfolge ändern.