VPN üzerinden PostgreSQL: pg_hba hangi kaynak adresini görecek

PostgreSQL bir istemcinin VPN'de olduğunu asla öğrenmez. Bir adresten TCP bağlantısı ve bir kimlik bilgileri kümesi alır ve bunlarla ne yapacağına karar verir. Bu nedenle erişimi tünele bağlı hale getirmek, üç ayrı kararı birbiriyle uyumlu olacak şekilde düzenlemek ve ardından şemada çizdiğiniz adres yerine sunucunun gerçekte gördüğü tek adresi denetlemek anlamına gelir.

Birleştirilmemesi gereken üç karar

Sunucunun nerede dinlediği bir karardır. Hangi trafiğin o adrese ulaşabileceği ikincisidir ve bunu ana makinenin güvenlik duvarı ile önündeki her ağ sınırı verir. Hangi veritabanı kimliğinin hangi kaynaktan kimlik doğrulayabileceği üçüncüsüdür ve pg_hba.conf içinde verilir.

Her biri farklı bir bileşen tarafından uygulanır ve her biri farklı bir mesajla başarısız olur. Bunları bir tartışmada birleştirmek, insanların güvenlik duvarı sorununu çözmek için HBA dosyasını düzenlemesine yol açar. Bunları sırayla tutun: bağlanmamış bir dinleyiciye ulaşılamaz, filtrelenmiş bir bağlantı noktasına bağlanılamaz ve bir HBA kuralı yalnızca bağlantı var olduktan sonra ne olacağına karar verir. Bir değişikliğin etkisi yoksa, üç katmandan hangisini gerçekte değiştirdiğinizi belirleyin.

Sunucunun dinlediği yer

Arayüz adına değil, makineye gerçekte atanmış bir adrese bağlanın:

listen_addresses = '10.20.0.30'

Veritabanı, kendi tünel arayüzü olmadan VPN geçidinin arkasında durabilir ve bir adresin adlandırılması gereken doğru şey olmasının nedeni tam olarak budur. Bu ayarı değiştirmek tam bir yeniden başlatma gerektirir; yeniden yükleme yeterli değildir.

Ardından bağlantı noktasını, genellikle 5432'yi, ana makinede ve önündeki her sınırda filtreleyin. Özel bir adrese bağlanmak, genel olarak reddedildiğinin kanıtı değildir, çünkü bir bağlantı noktası yönlendirmesi veya bulut adres eşlemesi paketleri hâlâ o özel dinleyiciye teslim edebilir.

HBA'nın gerçekte gördüğü adres

Yönlendirilmiş erişimde sunucu her istemcinin iç tünel adresini görür. Kaynak çevirisinde bunun yerine geçidin çevrilmiş adresini görür ve her istemci o tek değerde birleşir. İzin verilecek öneki seçmeden önce kaynağı sunucunun kendi bağlantı kanıtları üzerinden inceleyin.

Zaten TLS ve SCRAM kullanan bir dağıtım için kasıtlı olarak dar bir uzaktan erişim örneği şöyle görünür:

hostssl appdb app_login 10.8.0.0/24 scram-sha-256
host all all 0.0.0.0/0 reject
host all all ::/0 reject

Bu, belirtilen havuzdan TLS üzerinden bir role ve bir veritabanına izin verir, ardından diğer uzak TCP erişimini reddeder. Tam bir HBA dosyasının yerini almaz: yerel yönetimi, çoğaltmayı ve diğer yetkili hizmetleri koruyun ve dar kuralları daha geniş izinlerden önce yerleştirin.

Çeviri işin içindeyken HBA, istemcileri özgün adreslerine göre ayırt edemez. Ağ kabulünü sıkı tutun ve gerçek veritabanı kimlik bilgileri isteyin ve trust kimlik doğrulamasını asla gerçek bir hesapla değiştirmeyin.

İlk eşleşme kazanır, yedek yok

PostgreSQL dosyayı yukarıdan aşağıya okur ve bağlantıyla eşleşen ilk kaydı kullanır. O kaydın kimlik doğrulaması başarısız olursa ikinci bir deneme yoktur, bu nedenle daha önceki geniş bir izin sonraki bir reddi sessizce geçersiz kılar.

Bu sıralama kuralı, dikkatle yazılmış bir reddin asla yürürlüğe girmemesinin en yaygın nedenidir. Belirli kuralları önce, geniş olanları sonra koyun ve ardından dosyayı bir küme değil dizi olarak okuyun. En alta eklediğiniz kural bir politika değil, bir yorumdur. Dosyanın yok sayıldığı sonucuna varmadan önce onu yukarı taşıyın ve yeniden yükleyin.

HBA başvurusu hem sırayı hem de host ve hostssl kayıtları arasındaki farkı tanımlar; bu, kuralın amacı bağlantının şifrelenmiş olması olduğunda önemlidir.

Yeniden yükleme, yeniden başlatma ve reddedilen durum

HBA değişiklikleri yeniden yükleme ile uygulanır ve pg_hba_file_rules görünümü ayrıştırma hatalarını bulmanıza yardımcı olur. Bu görünüm dosyanın mevcut içeriğini açıklar, çalışan sunucunun bunları başarıyla yükleyip yüklemediğini değil, bu nedenle temiz bir liste yeni kuralların etkin olduğunun kanıtı değildir.

Dinleyici değişiklikleri kendi yeniden başlatmalarını gerektirir ve bir değişikliğin etkisi yokmuş gibi göründüğünde iki işlemi karıştırmak kolaydır.

Yeni oturumlarla test edin: amaçlanan hesapla onaylanmış bir istemci bağlanır, aynı hesap onaylanmamış bir yoldan bağlanmaz ve yetkisiz bir veritabanı kimliği VPN'in içinden bile başarısız olur. Bu üç sonuç ağ sınırını veritabanı yetkilendirmesinden ayırır, ki kararları ayrı tutmanın tüm amacı budur.