VPN açıkken bulut güvenlik duvarı hangi adresi görür
Tam tünel, veritabanınızın gördüğü kaynak adresini değiştirir. İzin listesini, özel yolu veya bölünmüş tüneli taşıyın, kimlik bilgisini değil.
VPN bağlanmadan önce çalışan ve bağlandıktan sonra başarısız olan bir veritabanı nadiren kimlik bilgisi sorunudur. Bulut güvenlik duvarları kaynak adresleri eşleştirir ve tam tünel tam olarak eşleştirdikleri adresi değiştirir. Dizüstü bilgisayarınızın gönderdiğini düşündüğünüz şey ile sunucunun aldığı şey arasındaki fark hatanın tamamıdır ve tek adımda ölçülebilir.
Kaynak adres neye dönüşür
Tam tünelde her paket VPN ağ geçidinden çıkar, bu yüzden sunucu ev bağlantınız yerine ağ geçidinin çıkış adresini görür. Yolda bir yönlendirme proxy'si varsa gelen onun adresidir. İkisi de meşru kaynaktır ve hiçbiri özgün kuralınızdaki adres değildir.
Azure SQL'in sunucu ve veritabanı düzeyindeki güvenlik duvarı kuralları, mantıksal sunucuya ulaşan istemci adresini eşleştirir ve tam tünelden sonra bu çıkış adresidir. Tek adrese izin veren bir AWS güvenlik grubu da aynı şekilde davranır. Paket kimlik doğrulamadan önce düşürülür, bu yüzden aldığınız hata izin sorunu değil ağ arızası gibi görünür. İnsanların parola sıfırlamaya başlamasının nedeni tam olarak budur.
İzin listesi nerede kararlaştırılır
Başarısız yolla eşleşen kuralı okuyun, oluşturduğunuzu hatırladığınız kuralı değil. Kapsamını, bağlantı noktasını, protokolünü ve herhangi bir kimlik denetiminden önce değerlendirilip değerlendirilmediğini not edin.
Sonra kararın meşru olarak hangi katmana ait olduğuna karar verin. Adres kuralı trafiğin nereden geldiğini yanıtlar. Özel uç nokta, hizmete özel bir yoldan ulaşılıp ulaşılamadığını yanıtlar. Bölünmüş tünel istisnası hangi hedeflerin tüneli atladığını yanıtlar. Bunlar birbirinin yerine geçmez ve tünel değiştiğinde her biri farklı biçimde başarısız olur.
Üç onarım, üç katman
Aşağıdaki her seçenek akışı farklı bir nedenle düzeltir ve yanlış olanı seçmek bir sonraki ağ geçidi değişikliğine kadar çalışan bir bağlantı üretir.
| Repair | Layer it changes | What it does not fix |
|---|---|---|
| Add the egress address to the rule | Source address matching | Nothing about routing, and it breaks when the egress moves |
| Use a private endpoint | Whether the service is reached privately | A client that still resolves the public name |
| Add a split-tunnel exception | Which flows bypass the tunnel | An expired credential or a wrong password |
Çıkış adresini eklemek en küçük değişiklik ve en kırılgandır, çünkü yeni bir ağ geçidi veya farklı bir bölge onu sessizce geçersiz kılar. Adresi tünel tanımının yanına belgeleyin ki ikisi birlikte hareket etsin. Geçici geniş aralık bir teşhistir, onarım değil; yerinde bırakmak iç hizmetlerin sonunda açık kalma yoludur.
Yönetilen bir platform neden tünele katılamaz
Heroku, AppHarbor veya CloudBees gibi uygulama platformları kodunuzu tun veya tap aygıtı olmayan ve oluşturma yetkisi bulunmayan bir ortamda çalıştırır. Gelen trafik modeli HTTP'dir, keyfi bir dinleme soketi değil. VPN ikili dosyası taşıyan bir buildpack bile arayüzü koyacak yer bulamaz. İşleyen kalıplar veritabanının izin verebileceği statik bir çıkış adresi, platformun sunduğu özel bağlantı ürünü veya DMZ'de HTTPS ile erişilen bir proxy'dir.
O proxy kendi kimlik doğrulaması ve günlüklemesi olan bir erişim yoludur. Platformu VPN'inizin üyesi yapmaz ve böyle tanımlamak kimsenin denetleyemeyeceği kurallar üretir.
Başarısız olan istemciden doğrulayın
Yeniden bağlanın ve istemcinin tam yolunu yineleyin. Hizmetin günlüğe aldığı kaynak adresi, istemcinin veritabanı adı için seçtiği rotayı ve gerçek sorgunun sonucunu bu sırayla kontrol edin. Ağ geçidinden yapılan test ağ geçidinin çalıştığını kanıtlar, bu hiç kuşku konusu olmadı. Bağlantı artık kimlik doğrulamasından geçiyor ve sorgu hâlâ başarısızsa kalan sorun veritabanı iznidir.
Tünel her değiştiğinde bu kuralları gözden geçirin. Değiştirilen bir ağ geçidi veya yeni bir çıkış aralığı, uygulama yapılandırmasında hiçbir değişiklik olmadan yolu kırar.