VPN üzerinden MySQL localhost: hâlâ yerel süreci ifade ediyor

Ofis sunucusundaki uygulama localhost üzerinden MySQL'e bağlanıyor, siz bu ana bilgisayar adını masaüstü istemcisine kopyalıyorsunuz ve bağlantı ya başarısız oluyor ya da başka bir veritabanı açıyor. VPN kelimenin anlamını değiştirmedi: localhost hâlâ istemciyi çalıştıran makineyi gösteriyor. VPN paketleri taşıdı, arayüzleri değil. Bir yola dokunmadan önce dizüstü bilgisayarın hangi uç noktaya ulaşması gerektiğine karar verin.

Adım 1: dizüstü bilgisayarın hangi uç noktaya ulaşması gerektiğine karar verin

İki tasarım da meşrudur ve farklı sorulara yanıt verir. Doğrudan erişim, veritabanının tünelin ulaştığı özel bir adreste dinlediği ve dizüstü bilgisayarın o adrese bağlandığı anlamına gelir. Yönlendirilmiş erişim, veritabanının loopback üzerinde kaldığı ve bir SSH oturumunun bağlantı noktasını makinenize taşıdığı anlamına gelir. Birini bilerek seçin, çünkü ikisini karıştırmak yanlış nedenle çalışan bir bağlantı üretir.

Doğrudan erişim için veritabanı ana bilgisayarının kendi özel adını veya adresini ve bağlantı noktasını onu yönetenden alın. VPN ağ geçidinin adresi, aynı makine değilse veritabanının adresi değildir. Ardından dinleyicinin gerçekten o arayüze bağlı olduğunu doğrulayın, çünkü bir arayüze giden yol o arayüzde dinleyici oluşturmaz.

Adım 2: bağlantı noktasını yalnızca dinleyici yerel kalırsa yönlendirin

Veritabanı yalnızca loopback üzerinde kalacaksa, onu SSH üzerinden yönlendirin ve yerel ucu da loopback'e bağlayın. Soldaki bağlama adresi dizüstü bilgisayarınıza aittir; sağdaki hedef SSH sunucusunun tarafından yorumlanır, OpenSSH başvurusu'nun açıkladığı gibi. Bu iki rolü tersine çevirmek, bir yönlendirmenin çalışıyor gibi görünüp hiçbir şeye bağlanmamasının olağan nedenidir.

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

SSH veritabanı ana bilgisayarı yerine bir atlama ana bilgisayarına inerse, sağdaki loopback atlama ana bilgisayarını gösterir ve hedefin o ana bilgisayarın ulaştığı bir adrese değişmesi gerekir. ExitOnForwardFailure yönlendirmenin kurulamamasını yakalar, ancak hedefe yapılan sonraki bağlantıların başarılı olduğunu kanıtlamaz. Ana bilgisayar anahtarı denetimini açık tutun ve yönlendirme bağlantı noktasını tüm arayüzlere bağlayarak tüm LAN'ınıza sunmayın.

Veritabanı yalnızca loopback üzerinde kalacaksa ve SSH kullanamıyorsanız durun. O zaman doğrudan erişim yanlış tasarımdır, zorlanacak bir yapılandırma değil.

Adım 3: istemciyi TCP'ye zorlayın

Unix'te localhost verilen bir MySQL istemcisi varsayılan olarak bir Unix soketi seçer, bu yüzden yalnızca bağlantı noktasını değiştirmek onu yönlendirmenizle hiçbir ilgisi olmayan bir soket ararken bırakabilir. Açık TCP protokolünü ve loopback adresini kullanarak istemcinin yönlendirme bağlantı noktanıza bir bağlantı açmasını sağlayın.

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

Değersiz parola seçeneği sırrı komut satırına koymak yerine sorar ve bu, korunmaya değer alışkanlıktır. Diğer araçların aynı ayrım için kendi anahtarları vardır ve bazı sürücüler localhost'u da özel olarak ele alır. Bayrağın taşındığını varsaymak yerine istemcinizin ne yaptığını denetleyin. Veritabanı hesabı ayrıca sunucunun gördüğü kaynakla eşleşen bir izin gerektirir ve bu, dizüstü bilgisayarınız değil, yönlendirme ana bilgisayarıdır.

Araç TCP'ye zorlanamıyorsa durun. O zaman başka bir istemci kullanın veya özel dinleyiciye doğrudan erişim kullanın.

Adım 4: gerçekte hangi uç noktaya ulaştığınızı kanıtlayın

Sunucuya bağlantının ne olduğunu düşündüğünü sorun. Ana bilgisayar adı, bağlantı noktası ve soket değişkenleri TCP üzerinden gelip gelmediğinizi ve hangi dinleyicinin yanıt verdiğini söyler, bağlantı listesi sunucunun kaydettiği kaynak adresini gösterir. Bu kanıt bir başka yol değişikliğinden daha faydalıdır.

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

Hangi uç noktayı denediğinizi kaydedin: yerel Unix soketi, yönlendirme bağlantı noktanız veya özel dinleyici. Bu üç başarısızlığın düzeltmeleri farklıdır ve istemci hâlâ yanlış localhost ile konuşurken VPN yolunu değiştirmek boşa çabadır. Notlarda SSH kimlik doğrulaması ile veritabanı kimlik doğrulamasını ayrı tutun, çünkü masaüstü istemcisinden birindeki başarısızlık diğerindeki başarısızlık gibi görünür. Ardından işiniz bitince yönlendirmeyi kaldırın.

Kontrol listesi, uç noktayı, istemci protokolünü, sunucunun gördüğü kaynak adresini ve buna izin veren yetkiyi adlandırabildiğinizde biter. Dört olgu ve bir sonraki bağlantı sorunu bir öğleden sonra yerine dakikalar alır.