SQL Server, açılışta olmayan bir VPN adresine bağlanıyor

Hizmet hâlâ çalışırken başarısız bir bağlanmayla ilgili SQL Server günlük satırını okuyun ve bir çökme değil, başlangıç sırasına bağımlılık bulmuş olursunuz. İşte bu birleşim ipucudur: motor, dinlemesi söylenen adres makinede var olmadan önce başlamıştı. Oturum açmadan sonra ortaya çıkan bir VPN bağdaştırıcısı, gözetimsiz bir veritabanı hizmeti için kötü bir ön koşuldur, bu yüzden hatayı motorun gördüğü sırayla izleyin.

İstemciden değil, başlangıç günlüğünden başlayın

Örneğin hata günlüğünü açın ve yalnızca son satırı değil, ağ başlatma çevresindeki girdileri okuyun. Motor hangi adresleri denediğini ve hangi protokolleri etkinleştirdiğini bildirir ve bu kayıt herhangi bir istemci bağlanmadan öncesine aittir. Şimdi ana makinede şu anda ne olduğuna bakın. Yapılandırılmış adrese sahip arabirim yalnızca bir kullanıcı oturum açıp istemci başlattıktan sonra ortaya çıkıyorsa, adres açılışta yoktu ve bağlanma hatası tamamen açıklanmış olur.

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixOrigin
Get-Content 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\LOG\ERRORLOG' -Tail 40

Örneğin yolunu kurulumunuza göre ayarlayın ve sonuç çıkarmadan önce arabirim listesini okuyun. Var olan ama yanlış bağdaştırıcıya ait olan adres, henüz var olmayan adresten farklı bir sorundur.

Motorun gerçekte izlediği bağlanma sırasını adımlayın

Motor dinleyici yapılandırmasını okur, sonra işletim sisteminden bağlanmasını ister. Adres o anda yerel değilse, o adres için bağlanma başarısız olur, örneğin geri kalanı normal şekilde devam edebilir. Bu yüzden diğer protokoller veya diğer adresler hâlâ çalışabilir ve bu yüzden „SQL Server kapalı“ yanlış özettir. Günlükteki tam uç noktayı koruyun: adres, bağlantı noktası ve protokol, çünkü düzeltme bu üçünden hangisinin yanlış olduğuna bağlıdır.

Bağdaştırıcı ortaya çıktıktan sonra hizmeti yeniden başlatmak dinleyiciyi genellikle başarılı kılar ve asıl tuzak budur. Bağımlılığı ortadan kaldırmak yerine kanıtlar ve tünel her yeniden bağlandığında bağlı her kullanıcının bağlantısını keser.

Dinleyiciyi motorun okuduğu gibi okuyun

SQL Server Configuration Manager'da örneğin TCP/IP özelliklerini açın ve tek tek adresleri düzenlemeden önce Listen All ayarını not edin. Listen All Yes olduğunda adres başına Enabled değerleri yok sayılır, bu yüzden bunları düzenlemek dinleyicinin kullandığı hiçbir şeyi değiştirmez. Üç şeyi sırayla kaydedin: hizmet vermeyi düşündüğünüz adres, bağlantı noktası ve dinleyicinin tüm adresleri mi yoksa yalnızca birini mi kapsayacağı. Ardından değişikliği desteklenen yeniden başlatma yordamıyla uygulayın ve motorun istediğinizi bağladığını doğrulamak için sonraki başlangıç günlüğünü okuyun.

Her adreste dinlemek erişim denetimi değildir. Gerçekten geniş bir dinleyici gerekiyorsa, erişilebilen her arabirimin kendi güvenlik duvarı ve veritabanı yetkilendirme kararına ihtiyacı vardır; internete bakan arabirimler de dahil.

İstemciye kararlı bir hedef verin

İstemcinin veritabanı ana makinesinin havuz adresi taşımasına ihtiyacı yoktur. Yönlendirilmiş bir tasarım, sunucu kararlı özel adresinde dinlerken VPN geçidi istemcinin trafiğini ona iletir ve yanıtı geri getirir.

Test-NetConnection -ComputerName 10.80.0.15 -Port 1433
tracert -d 10.80.0.15

İstemci 10.80.0.15'e ulaşırsa yol kanıtlanmıştır ve veritabanının yalnızca o istemciyi yetkilendirmesi gerekir. Ulaşmazsa, dinleyiciye yeniden dokunmadan önce yönlendirmeyi ve DNS'i düzeltin, çünkü sunucudaki bağlanma sorunu bir istemcinin onu bulamamasının nedeni hiçbir zaman değildi. Sunucuya sahte bir havuz adresi veya dinleyiciyi memnun etmek için ikinci bir varsayılan geçit eklemek, eski sorunun üzerine yeni bir ağ sorunu yaratır. Sunucunun adreslemesini statik tutun ve tünelin istemcileri ona getirmesine izin verin.

İstemcinin kullandığı uç noktayı doğrulayın

Bağlantı noktası testi yerine uygulama düzeyinde bir denetimle bitirin. İstemciden uygulamanın kullandığı hesapla bağlanın ve sunucu tarafındaki bağlantı ayrıntılarını okuyun; bunlar oturumunuzun indiği yerel adresi gösterir.

sqlcmd -S tcp:10.80.0.15,1433 -Q "SELECT local_net_address, local_tcp_port FROM sys.dm_exec_connections WHERE session_id = @@SPID"

Bu adresi yapılandırdığınız dinleyiciyle karşılaştırın. Bir uyuşmazlık ikinci bir dinleyici veya beklenmedik bir yerde çözülen bir ad anlamına gelir ve sonraki yeniden başlatma düzeltmenizi sizin yerinize test etmeden önce ikisini de bilmekte yarar var. Ardından ana makineyi oturum açmış kullanıcı olmadan yeniden başlatın ve bağlanmanın başarılı olduğunu doğrulayın. O tek test, onarılmış bir dinleyici ile sonraki yama gecesinde başarısız olan geçici bir çözüm arasındaki farktır.