PostgreSQL melalui VPN: alamat sumber mana yang akan dilihat pg_hba

PostgreSQL tidak pernah mengetahui bahwa klien berada di VPN. Ia menerima koneksi TCP dari sebuah alamat dan sekumpulan kredensial, lalu memutuskan apa yang akan dilakukan dengannya. Karena itu, membuat akses bergantung pada terowongan berarti menyusun tiga keputusan terpisah agar saling cocok, lalu memeriksa satu-satunya alamat yang benar-benar dilihat server alih-alih alamat yang Anda gambar pada diagram.

Tiga keputusan yang tidak boleh dilebur

Di mana server mendengarkan adalah satu keputusan. Lalu lintas mana yang dapat mencapai alamat itu adalah keputusan kedua, yang diambil oleh firewall host dan setiap batas jaringan di depannya. Identitas basis data mana yang boleh mengautentikasi dari sumber mana adalah keputusan ketiga, yang diambil di pg_hba.conf.

Masing-masing ditegakkan oleh komponen yang berbeda, dan masing-masing gagal dengan pesan yang berbeda. Meleburnya dalam sebuah diskusi adalah cara orang akhirnya menyunting berkas HBA untuk memperbaiki masalah firewall. Jaga urutannya: pendengar yang tidak terikat tidak dapat dijangkau, port yang tersaring tidak dapat dihubungi, dan aturan HBA hanya menentukan apa yang terjadi setelah koneksi ada. Ketika suatu perubahan tidak berefek, kenali lapisan mana dari ketiganya yang sebenarnya Anda ubah.

Di mana server mendengarkan

Ikat ke alamat yang benar-benar ditetapkan ke mesin, bukan ke nama antarmuka:

listen_addresses = '10.20.0.30'

Basis data dapat berada di belakang gateway VPN tanpa antarmuka terowongan sendiri, dan itulah tepatnya mengapa alamat adalah hal yang benar untuk disebutkan. Mengubah pengaturan ini memerlukan restart penuh; muat ulang tidak cukup.

Lalu saring port, biasanya 5432, di host dan di setiap batas di depannya. Mengikat ke alamat privat bukan bukti penolakan publik, karena penerusan port atau pemetaan alamat cloud masih dapat mengirimkan paket ke pendengar privat itu.

Alamat yang benar-benar dilihat HBA

Dengan akses terutek, server melihat alamat terowongan dalam setiap klien. Dengan terjemahan sumber, ia melihat alamat gateway yang diterjemahkan, dan setiap klien menyatu menjadi satu nilai itu. Periksa sumber melalui bukti koneksi server sendiri sebelum Anda memilih prefiks untuk diizinkan.

Untuk penerapan yang sudah memakai TLS dan SCRAM, contoh akses jarak jauh yang sengaja sempit tampak seperti ini:

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

Ini mengizinkan satu peran dan satu basis data melalui TLS dari kumpulan yang disebutkan, lalu menolak akses TCP jarak jauh lainnya. Ini bukan pengganti berkas HBA lengkap: pertahankan administrasi lokal, replikasi, dan layanan lain yang diizinkan, dan tempatkan aturan sempit sebelum izin yang lebih luas.

Ketika terjemahan berperan, HBA tidak dapat membedakan klien berdasarkan alamat aslinya. Jaga penerimaan jaringan tetap ketat dan tuntut kredensial basis data yang nyata, dan jangan pernah mengganti autentikasi trust dengan akun sungguhan.

Kecocokan pertama menang, tanpa cadangan

PostgreSQL membaca berkas dari atas ke bawah dan memakai catatan pertama yang cocok dengan koneksi. Tidak ada percobaan kedua jika autentikasi catatan itu gagal, sehingga izin luas yang lebih awal secara diam-diam mengalahkan penolakan yang lebih akhir.

Aturan urutan itu adalah alasan paling umum mengapa penolakan yang ditulis dengan cermat tidak pernah berlaku. Letakkan aturan spesifik lebih dulu dan yang luas terakhir, lalu baca berkas sebagai urutan, bukan sebagai himpunan. Aturan yang Anda tambahkan di bagian bawah bukanlah kebijakan, melainkan komentar. Pindahkan ke atas dan muat ulang sebelum Anda menyimpulkan bahwa berkas itu diabaikan.

Referensi HBA mendefinisikan baik urutan maupun perbedaan antara catatan host dan hostssl, yang penting ketika inti aturannya adalah koneksi harus terenkripsi.

Muat ulang, mulai ulang, dan kasus penolakan

Perubahan HBA diterapkan dengan muat ulang, dan tampilan pg_hba_file_rules membantu Anda menemukan kesalahan penguraian. Tampilan itu menjabarkan isi berkas saat ini, bukan apakah server yang berjalan berhasil memuatnya, jadi daftar yang bersih bukan bukti bahwa aturan baru aktif.

Perubahan pada pendengar memerlukan mulai ulang tersendiri, dan kedua operasi mudah tertukar ketika suatu perubahan tampak tidak berefek.

Uji dengan sesi baru: klien yang disetujui dengan akun yang dimaksud terhubung, akun yang sama dari jalur yang tidak disetujui tidak, dan identitas basis data yang tidak sah tetap gagal dari dalam VPN. Ketiga hasil itu memisahkan batas jaringan dari otorisasi basis data, yang justru menjadi inti menjaga keputusan tetap terpisah.