VPN üzerinden MySQL: şifrelemeyi değil, sunucuyu doğrulayın
Yanlış ana bilgisayara şifreleme yine yanlıştır. ssl-mode değerlerini karşılaştırın, ardından amaçladığınız sunucuyu adlandıran ve bunu kanıtlayan bir bağlantı çalıştırın.
Bir bağlantıyı şu adrese kaydediyorsunuz: 10.20.4.15, VPN düşüyor ve istemci yine de bağlanıyor. Bu iyi haber değil. Özel bir adres, bulunduğunuz hangi yönlendirme bağlamında olursanız olun oradaki bir konumdur ve birçok ağ aynı aralıkları kullanır. İstemci bir MySQL sunucusuna ulaştı, belki sadece sizinkine değil.
Düzeltmenin iki yarısı var ve bunlardan yalnızca biri ağla ilgili. Bağlantıyı amaçlanan yolunda tutun ve istemcinin konuştuğu sunucunun kimliğini doğrulamasını sağlayın. İlk yarı VPN'in yardımcı olduğu yerdir; ikinci yarı yapılandırılmalıdır.
Tam olarak neye şifrelenmiş?
TLS görüşmeyi aradaki herkesten korur ve istemci kontrol etmedikçe uç noktanın kim olduğunu iddia ettiği konusunda hiçbir şey söylemez. Güvenilir bir otoriteye karşı doğrulanan bir sertifika, sertifikanın o otoriteden geldiğini kanıtlar. Sertifikanın ulaşmak istediğiniz ana bilgisayar adı için verildiğini kanıtlamaz ve bunlar farklı sorulardır.
Bu teorik bir boşluk değil. Captive portallar, yanlış VRF hataları ve çakışan adres planları hepsi sizinle TLS müzakere etmeye tamamen hazır bir sunucu üretir. İstemci yalnızca şifreleme talep ediyorsa oturum özeldir ancak yanlış veritabanına yönelmiştir.
Dolayısıyla ilgili soru bağlantının şifreli olup olmadığı değil, amaçladığınız kimliğe şifreli olup olmadığıdır. MySQL istemcisinde bu ayrım tamamen ssl-mode ayarında yaşar.
Pratikte beş ssl-mode değeri
Beş değer vardır ve bunlardan yalnızca biri bu kılavuzun sorusunu yanıtlar. Tablo, adının ima ettiğini değil, her birinin gerçekte neyi garanti ettiğini listeler.
| 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 |
Bu makaledeki soruyu yalnızca son satır yanıtlar. PREFERRED kendi başına dikkate değer, çünkü sessizce düz metne düşen bir istemci reddedenden daha kötüdür: şifrelemeniz olduğuna inanırsınız ve paket kaydı buna katılmaz.
Bugün çalıştırabileceğiniz bir bağlantı
Aşağıdaki komut kullanılacak biçimdir, iki yer tutucuyla: onaylanmış veritabanı adı ve onaylanmış bir kanaldan alınmış CA dosyası. İkisi de sunucunun ilk temasta önerdiğinden alınmamalıdır.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password değer olmadan istemde bulunur, bu da sırrı süreç listesinin ve kabuk geçmişinizin dışında tutar. Paylaşılan atlama ana bilgisayarlarında büyük getirisi olan küçük bir alışkanlıktır, çünkü komut satırı diğer kullanıcılar tarafından görülebilir.
Bu başarısız olduğunda hata metni durumları sezgiden daha iyi ayırır. CA hatası zincirin doğrulanmadığı anlamına gelir ve sunucu sertifikasını hangi CA'nın imzaladığına bakmalısınız. Ana bilgisayar adı hatası zincirin iyi olduğu ve adın eşleşmediği anlamına gelir; bu genellikle yanlış sunucuya değil, doğru sunucuya yanlış adla bağlandığınızı gösterir.
Bir istemin görünmesi parolanın zaten iletildiğinin kanıtı değildir ve başarısız bir bağlantı istemciden hiçbir şeyin çıkmadığını kanıtlamaz. Geçmiş bir olayı yeniden oluşturuyorsanız istemciyi, yapılandırmasını, kimlik doğrulama eklentisini ve başarısız olan aşamayı belirleyin. Maruziyeti son hata iletisinden tahmin etmek tahmindir.
Ad bir tünelden geldiğinde
Yerel bağlantı noktası yönlendirmesi kimlik denetimini insanları şaşırtan bir şekilde bozar. Yerel bir bağlantı noktasını veritabanına yönlendirip localhost adresine bağlanırsanız istemci sertifikayı localhost adresine karşı doğrular ve o ad için hiçbir sertifika verilmemiştir. Bağlantı tamamen güvenli olabilir ve doğrulama yine de başarısız olur; bu, doğrulamanın amaçlandığı gibi çalışmasıdır.
İki dürüst yanıt var. Yönlendirilen uç noktaya loopback adresine çözülen ve sunucu sertifikasında görünen bir ad verin ya da istemcinin gerçek kimliği doğrulaması için ana bilgisayar adını baştan sona kullanın. Birincisi geliştiriciler için uygundur ve sertifika işi gerektirir; ikincisi düşünmesi daha kolaydır ve otomasyon için çoğu zaman doğru varsayılandır. Yönlendirmenin çalışması için doğrulamayı kapatmak, eklemeye çalıştığınız özelliği çöpe atar.
Kabul üç koşuldur
Kabul testini üç ayrı ifade olarak yazın: bağlantı amaçlanan yolu kullandı, şifreleme tercih değil zorunluydu ve sunucunun kimliği güvenilir malzemeye karşı doğrulandı. Yeşil bir VPN simgesi bunlardan hiçbirini tesis etmez.
GUI istemcileri ve MariaDB için bayrağın yazımının olduğu gibi geçtiğini varsaymak yerine satıcının kendi belgelerine bakın. MySQL'in şifreli bağlantılar belgeleri modlar arasındaki farkları ve CA dağıtım gereksinimini kapsar ve üretim bağlantı dizesini değiştirmeden önce kontrol edilmesi gereken referanstır.