Hayır, bir bağlantı dizesi VPN tünelinizi başlatamaz

Geliştiriciler bir bağlantı dizesinin, JDBC URL'sinin veya tnsnames.ora girdisinin VPN'i seçtiği yeri hâlâ arıyor. Böyle bir yer yok. Tüneli, sanal bir bağdaştırıcı kaydeden işletim sistemi veya bir satıcı istemcisi kurar ve üstündeki her veritabanı kitaplığı bundan doğan soket katmanını kullanır. Bağlantı dizesi bir ana makine, bir bağlantı noktası ve bir kimlik bilgisi adlandırır ve bütün sözlük bundan ibarettir.

Efsane: bağlantı dizesi bir tünel seçebilir

Sürücü bir ana makineye ve bağlantı noktasına TCP soketi açar. Tünel kaldırmak için API'si, tünel profili için alanı ve bir VPN ağ geçidine kimlik doğrulama yolu yoktur.

Bu yüzden bir yol oluştuğunda araçlar aynı davranır. SSMS, DBeaver, Eclipse Data Tools ve sıradan bir sqlcmd, sunucu yerel ağdaymış gibi davranır, çünkü soketin bakış açısından öyledir. Sanal bağdaştırıcı veritabanı alt ağını erişilebilir kıldı ve sürücü bunun nasıl olduğunu asla bilmez.

Bu aynı zamanda bir bağlantı dizesinin kopmuş bir tüneli neden onaramadığını açıklar. Bağlantı öldüğünde sürücü bir zaman aşımı veya genel bir ağ hatası bildirir ve bunu bir sorgu sorunu sayan uygulama kodu sonsuza dek yanlış katmanı yineler.

Tüneli sürücü çalışmadan önce kaldırın

VPN'e işletim sistemi düzeyinde, sağlayıcının veya ağ ekibinin talimatlarını izleyerek bağlanın ve ancak ondan sonra aracı açın. Pratikte bu, sürücü ana makine adını çözmeden önce veritabanı alt ağına bir yol bulunduğu anlamına gelir.

Tünel gözetimini uygulamanın dışında tutun. Bağlantıyı kendisi kaldırmaya çalışan bir PHP veya Java hizmeti, bir sağlayıcının davranışını iş koduna gömer ve her yük devretme bir uygulama sürümü hâline gelir. Tünele sahip olan, onu izleyen ve yeniden başlatan bir gözetleyici, sorgu yolundan ayrı bir konudur.

Sürücüyü suçlamadan önce yolu kontrol edin: ana makine çözümlenmiyorsa veya bağlantı noktası kabuktan yanıt vermiyorsa, hiçbir bağlantı dizesi bunu değiştirmez.

Efsane: Windows kimlik doğrulama hatası yolun bozuk olduğu anlamına gelir

VPN üzerinden Windows kimlik doğrulaması çoğu zaman ağ arızasına benzeyen bir hatayla başarısız olur, oysa yol sağlamdır. Hesap başka bir etki alanına aitse ve dizüstü bilgisayar ona katılamıyorsa, istemciyi masaüstü oturumunun kimliği yerine açık kimlik bilgileriyle başlatın.

runas /noprofile /netonly /user:CORP\dbreader "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"

/netonly anahtarı bu kimlik bilgilerini yalnızca uzaktan kimlik doğrulama için saklar. Bağlantı iletişim kutusuna güvenmek yerine SELECT SUSER_SNAME() ile sunucunun gerçekte ne aldığını doğrulayın. Sunucu adresi için kimlik bilgisini Windows Credential Manager'da saklamanın SSMS için çalıştığı ancak başka bir hesap altında çalışan bir hizmet için her zaman çalışmadığı bildiriliyor, bu yüzden oturum açmayı değiştirmeden önce sürecin hangi kimliği kullandığını kontrol edin.

Gecikme, sunucu tarafındaki imleci zaman aşımına dönüştürür

Sunucu tarafındaki imleç, veritabanından sonucu tutmasını ve aşamalı olarak getirmesini ister; bu, tek bir büyük sonucu çok sayıda küçük gidiş dönüşe çevirir. Yerel ağda bu ucuzdur. Onlarca milisaniye ek gecikme içeren bir tünel üzerinden aynı sorgu, neredeyse hiç veri aktarmadan komut zaman aşımını aşabilir.

İstemci tarafındaki imlece geçin veya getirme boyutunu artırıp satırları toplu işleyin; gidiş dönüş sayısı düşer. Darboğaz, bağlantının nominal hızı değil, alışveriş sayısıdır; bu yüzden aktarım hızını ölçmek sizi yanıltır, gidiş dönüşleri ölçmek yanıltmaz. Kullanıcılarınızın gerçekten çektiği en büyük sonuç kümesiyle test edin, anında dönen tek satırlık bir sorguyla değil. Zaman aşımı yer değiştiriyor ama kaybolmuyorsa, komut zaman aşımını ve getirme boyutunu birlikte artırıp yeniden ölçün.

Aynı aritmetik, çok konuşan ORM'lar ve her satır için bir ifade gönderen her istemci için geçerlidir. Sorgu planı iyiyse ve aktarım küçükse, veritabanını ayarlamadan önce ağ alışverişlerini sayın.

Bağlantı noktasını, örneği ve yerel filtreyi kontrol edin

Adlandırılmış bir örnek dinamik bir bağlantı noktasında dinler, bu yüzden 1433 varsaymak yerine bağlantı noktasını doğrulayın. Varsayılan bir örnekte değer, örneğin SuperSocketNetLib anahtarı altındaki TcpPort kayıt değerinden okunabilir. Oracle için tnsnames.ora içindeki ana makinenin çözümlendiğini, adresin yanıt verdiğini ve dinleyici bağlantı noktasına izin verildiğini doğrulayın; 1521 yaygın bir varsayılandır, garanti değil.

Ardından tünelin kendi erişim listesini ve son olarak istemci ile sunucu aynı makine olsa bile bağlantıyı engelleyen yerel bir antivirüsü veya ana makine güvenlik duvarını eleyin. Yapılandırmayı değiştirmeden önce başarısız olan aşamayı kaydedin, çünkü ad çözümleme, TCP erişilebilirliği ve TLS veya oturum açma her biri farklı bir iletiyle başarısız olur.

Aşamayı bilete yazın. Aksi hâlde bir sonraki kişi her şeyi başlatan aynı bağlantı dizesi aramasını yineler.