MySQL localhost melalui VPN: ia masih bermaksud proses setempat

Apl pada pelayan pejabat menyambung ke MySQL pada localhost, anda menyalin nama hos itu ke klien desktop, dan sambungan sama ada gagal atau membuka pangkalan data lain. VPN tidak mengubah makna perkataan itu: localhost masih merujuk kepada mesin yang menjalankan klien. VPN memindahkan paket, bukan antara muka. Tentukan titik akhir mana yang perlu dicapai oleh komputer riba sebelum anda menyentuh mana-mana laluan.

Langkah 1: tentukan titik akhir mana yang perlu dicapai oleh komputer riba

Kedua-dua reka bentuk sah dan menjawab soalan yang berbeza. Akses terus bermaksud pangkalan data mendengar pada alamat peribadi yang dapat dicapai oleh terowong, dan komputer riba menyambung ke alamat itu. Akses dihantar bermaksud pangkalan data kekal pada loopback dan sesi SSH membawa port ke mesin anda. Pilih satu dengan sengaja, kerana mencampurkannya menghasilkan sambungan yang berfungsi atas sebab yang salah.

Untuk akses terus, dapatkan nama atau alamat peribadi hos pangkalan data itu sendiri dan portnya daripada pihak yang menguruskannya. Alamat get laluan VPN bukan alamat pangkalan data melainkan mesin yang sama. Kemudian pastikan pendengar benar-benar terikat pada antara muka itu, kerana laluan ke antara muka tidak mencipta pendengar di atasnya.

Langkah 2: hantar port hanya jika pendengar kekal setempat

Jika pangkalan data perlu kekal hanya pada loopback, hantarkannya melalui SSH dan ikat hujung setempat pada loopback juga. Alamat ikat di sebelah kiri milik komputer riba anda; sasaran di sebelah kanan ditafsirkan dari sisi pelayan SSH, seperti yang diterangkan rujukan OpenSSH. Membalikkan kedua-dua peranan itu ialah sebab biasa penghantaran kelihatan berfungsi tetapi tidak menyambung kepada apa-apa.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:13306:127.0.0.1:3306 [email protected]
ss -ltn 'sport = :13306'

Jika SSH mendarat pada hos lompat dan bukan hos pangkalan data, loopback di sebelah kanan merujuk kepada hos lompat itu, dan sasaran mesti ditukar kepada alamat yang dapat dicapai oleh hos tersebut. ExitOnForwardFailure menangkap kegagalan membentuk penghantaran, tetapi tidak membuktikan sambungan kemudian ke sasaran berjaya. Biarkan pemeriksaan kunci hos dihidupkan, dan jangan tawarkan port penghantaran kepada seluruh LAN anda dengan mengikatnya pada semua antara muka.

Berhenti jika pangkalan data mesti kekal hanya pada loopback dan anda tidak boleh menggunakan SSH. Maka akses terus ialah reka bentuk yang salah, bukan konfigurasi yang perlu dipaksa.

Langkah 3: paksa klien menggunakan TCP

Pada Unix, klien MySQL yang diberi localhost memilih soket Unix secara lalai, jadi menukar port sahaja boleh membiarkannya mencari soket yang tidak ada kaitan dengan penghantaran anda. Gunakan protokol TCP eksplisit dan alamat loopback supaya klien membuka sambungan ke port penghantaran anda.

mysql --protocol=TCP --host=127.0.0.1 --port=13306 --user=DB_USER --password

Pilihan kata laluan tanpa nilai akan bertanya dan bukannya meletakkan rahsia pada baris arahan, dan itulah tabiat yang wajar dikekalkan. Alat lain mempunyai suis sendiri untuk perbezaan yang sama, dan sesetengah pemacu juga melayan localhost secara khas. Periksa apa yang klien anda lakukan dan bukannya menganggap bendera itu dibawa. Akaun pangkalan data juga memerlukan kebenaran yang sepadan dengan sumber yang dilihat oleh pelayan, iaitu hos penghantaran dan bukan komputer riba anda.

Berhenti jika alat itu tidak boleh dipaksa menggunakan TCP. Maka gunakan klien lain, atau gunakan akses terus ke pendengar peribadi.

Langkah 4: buktikan titik akhir mana yang sebenarnya anda capai

Tanya pelayan apa yang disangkanya sambungan itu. Pemboleh ubah nama hos, port dan soket memberitahu sama ada anda tiba melalui TCP dan pendengar mana yang menjawab, dan senarai sambungan menunjukkan alamat sumber yang dicatatkan oleh pelayan. Bukti itu lebih berguna daripada perubahan laluan yang lain.

mysql --protocol=TCP -h 127.0.0.1 -P 13306 -u DB_USER -p -e "SELECT @@hostname, @@port, @@socket"

Catat titik akhir mana yang anda cuba: soket Unix setempat, port penghantaran anda atau pendengar peribadi. Ketiga-tiga kegagalan itu mempunyai pembaikan yang berbeza, dan menukar laluan VPN semasa klien masih bercakap dengan localhost yang salah ialah usaha yang sia-sia. Simpan juga pengesahan SSH dan pengesahan pangkalan data secara berasingan dalam nota, kerana kegagalan pada satu kelihatan seperti kegagalan pada yang lain daripada klien desktop. Kemudian buang penghantaran itu apabila anda selesai.

Senarai semak berakhir apabila anda boleh menamakan titik akhir, protokol klien, alamat sumber yang dilihat oleh pelayan dan kebenaran yang membenarkannya. Empat fakta, dan masalah sambungan seterusnya mengambil masa beberapa minit dan bukannya satu petang.