MariaDB melalui VPN: user@host mana yang dilihat server?
Akun dipilih berdasarkan pengguna dan host bersama-sama. Temukan sumber yang dilihat server, baca CURRENT_USER(), lalu perbaiki baris itu, bukan izinnya.
Ketik nama pengguna yang sama dari dua jalur berbeda dan MariaDB mungkin mengautentikasi Anda sebagai dua akun berbeda. Akun dikunci berdasarkan pengguna dan host bersama-sama, sehingga 'reporter'@'localhost' dan 'reporter'@'10.90.0.23' adalah baris terpisah dengan kata sandi terpisah dan izin terpisah. Melalui VPN, pertanyaan menariknya bukan nama apa yang diketik pengguna, melainkan alamat sumber apa yang dilihat server.
Tentukan sumber yang benar-benar dilihat server
Bekerjalah mundur dari host basis data, bukan dari laptop. Alamat yang diyakini dimiliki klien hanyalah salah satu dari beberapa kemungkinan:
| Path | Source MariaDB sees |
|---|---|
| Routed tunnel, no translation | The client's inner VPN address |
| Gateway source translation | The gateway's translated address |
| SSH local forward | The SSH server's address |
| Public exit, no tunnel | Whatever the ISP handed out |
Gunakan bukti sisi server untuk memutuskan. Log koneksi, daftar sesi aktif, atau entri sementara di log umum menunjukkan alamat yang diterima server. IP publik laptop dari peramban adalah fakta lain dan sering menyesatkan.
Cocokkan akun yang dipilih MariaDB
Pemilihan akun mengikuti urutan yang didokumentasikan, bukan gabungan izin. Kecocokan host persis lebih diutamakan daripada karakter pengganti, dan baris pengguna anonim ikut serta dalam pencocokan dengan cara yang mengejutkan orang yang menganggap nama saja yang menentukan. Server memilih satu baris; server tidak menggabungkan hak istimewa setiap baris bernama sama. Membaca referensi sekali lebih berharga daripada seharian mencoba dugaan.
Artinya, menambahkan izin ke 'reporter'@'%' mungkin tidak mengubah apa pun jika sesi terautentikasi sebagai 'reporter'@'10.90.0.23'. Perbaikan harus mendarat pada baris yang dipilih, itulah sebabnya mengidentifikasi akun mendahului menyunting izin.
Baca akun yang benar-benar digunakan sesi
SELECT USER(), CURRENT_USER();
SHOW GRANTS;CURRENT_USER() menyebut akun yang mengautentikasi sesi; USER() melaporkan apa yang diminta klien dan bisa berbeda. Jalankan sebagai kueri tingkat atas biasa, bukan dari dalam rutin tersimpan dengan konteks pendefinisi, atau jawabannya menjelaskan pemilik rutin alih-alih sesi Anda.
Login yang gagal tidak dapat menjalankan semua ini, dan itulah kasus ketika administrator harus memeriksa definisi akun dan bukti koneksi server. Rencanakan itu: orang yang men-debug login yang ditolak biasanya tidak memiliki sesi SQL untuk bertanya.
Pisahkan keterjangkauan dari autentikasi
Teks kesalahan memberi tahu Anda di lapisan mana Anda berada. Koneksi yang ditolak atau waktu tunggu habis berarti klien tidak pernah mencapai pendengar, jadi akun dan kata sandinya belum dipertanyakan. Balasan akses ditolak berarti server menjawab, yang membuktikan keterjangkauan dan mengarah ke akun, kecocokan host, atau kredensial.
Prasyarat jaringan adalah daftarnya sendiri: pendengar yang terikat ke alamat yang dimaksud dan bukan hanya ke loopback, lalu lintas yang diizinkan ke port yang dikonfigurasi, dan rute balik untuk balasannya. Masing-masing dapat gagal secara independen, dan terowongan yang berfungsi tidak menyiratkan satu pun darinya. Pendengar di loopback menerima koneksi lokal dan menolak setiap koneksi jarak jauh, yang menghasilkan koneksi ditolak yang tampak seperti blokir firewall.
Periksa alamat pengikatan sebelum membuka tiket ke tim jaringan. ss -lntp di host basis data menunjukkan alamat dan port mana yang benar-benar mendengarkan, dan satu baris itu menyingkirkan seluruh kategori dugaan.
Perbaiki secara sempit, lalu uji ulang kedua arah
Buat akun berkualifikasi host yang dimaksud melalui proses organisasi yang disetujui, dengan kredensial dari penyimpanan yang didukung alih-alih yang dibagikan dan ditempelkan ke tiket. Berikan hanya operasi skema yang dibutuhkan tugas. Mengubah login jarak jauh yang gagal menjadi akun root, kebijakan beri-semua, atau host karakter pengganti menyeluruh membuat pengujian lolos dan menghilangkan kendali yang Anda uji. Izin yang Anda tambahkan terburu-buru adalah yang tidak dihapus siapa pun nanti.
Uji ulang dengan sesi baru melalui jalur yang dimaksud, lalu periksa kasus negatif. Jalur yang seharusnya diblokir harus tetap diblokir, dan operasi yang tidak diberikan harus tetap ditolak. Dua pemeriksaan itulah yang membedakan akun yang diperbaiki dari akun yang diperlebar.
Terakhir, catat alamat sumber yang diamati dan nama akun bersama-sama. Terowongan menyediakan keterjangkauan; MariaDB tetap memilih dan mengotorisasi akunnya sendiri, dan orang berikutnya membutuhkan kedua fakta untuk mereproduksi hasil Anda.