Tidak, rentetan sambungan tidak boleh memulakan terowong VPN anda

Pembangun terus mencari tempat di mana rentetan sambungan, URL JDBC atau entri tnsnames.ora memilih VPN. Tempat itu tidak wujud. Terowong dibina oleh sistem pengendalian atau klien vendor yang mendaftar penyesuai maya, dan setiap pustaka pangkalan data di atasnya menggunakan lapisan soket yang terhasil. Rentetan sambungan menamakan hos, port dan kelayakan, dan itulah seluruh kosa kata.

Mitos: rentetan sambungan boleh memilih terowong

Pemacu membuka soket TCP ke hos dan port. Ia tiada API untuk menaikkan terowong, tiada medan untuk profil terowong dan tiada cara untuk mengesahkan diri ke get laluan VPN.

Itulah sebabnya alat berkelakuan sama sebaik sahaja laluan wujud. SSMS, DBeaver, Eclipse Data Tools dan sqlcmd biasa bertindak seolah-olah pelayan berada di rangkaian tempatan, kerana dari sudut soket ia memang begitu. Penyesuai maya menjadikan subrang pangkalan data boleh dicapai, dan pemacu tidak pernah tahu bagaimana.

Ini juga menjelaskan mengapa rentetan sambungan tidak boleh membaiki terowong yang terputus. Apabila pautan mati, pemacu melaporkan tamat masa atau ralat rangkaian umum, dan kod aplikasi yang menganggapnya masalah pertanyaan mengulang lapisan yang salah selama-lamanya.

Naikkan terowong sebelum pemacu berjalan

Sambungkan VPN pada peringkat sistem pengendalian, mengikut arahan pembekal atau pasukan rangkaian, dan hanya selepas itu buka alat tersebut. Dalam amalan ini bermakna laluan ke subrang pangkalan data wujud sebelum pemacu menyelesaikan nama hos.

Kekalkan penyeliaan terowong di luar aplikasi. Perkhidmatan PHP atau Java yang cuba menaikkan pautan sendiri mengekod kelakuan satu pembekal ke dalam kod perniagaan, dan setiap kegagalan alih menjadi pelepasan aplikasi. Penyelia yang memiliki terowong, memantaunya dan memulakannya semula ialah perkara berasingan daripada laluan pertanyaan.

Periksa laluan sebelum menyalahkan pemacu: jika hos tidak diselesaikan atau port tidak menjawab dari shell, tiada rentetan sambungan akan mengubahnya.

Mitos: kegagalan pengesahan Windows bermakna laluan rosak

Pengesahan Windows melalui VPN sering gagal dengan ralat yang kelihatan seperti kerosakan rangkaian, sedangkan laluan elok. Apabila akaun milik domain lain dan komputer riba tidak dapat menyertainya, mulakan klien dengan kelayakan jelas dan bukannya identiti sesi desktop.

runas /noprofile /netonly /user:CORP\dbreader "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"

Suis /netonly menyimpan kelayakan itu untuk pengesahan jauh sahaja. Sahkan apa yang sebenarnya diterima pelayan dengan SELECT SUSER_SNAME() dan bukannya mempercayai dialog sambungan. Dilaporkan bahawa menyimpan kelayakan untuk alamat pelayan dalam Windows Credential Manager berfungsi untuk SSMS tetapi tidak selalu untuk perkhidmatan yang berjalan di bawah akaun lain, jadi periksa identiti mana yang digunakan oleh proses sebelum menukar log masuk.

Kependaman menukar kursor sebelah pelayan menjadi tamat masa

Kursor sebelah pelayan meminta pangkalan data menyimpan hasil dan mengambilnya secara berperingkat, yang menukar satu hasil besar menjadi banyak perjalanan pergi balik kecil. Di LAN itu murah. Melalui terowong dengan puluhan milisaat kependaman tambahan, pertanyaan yang sama boleh melebihi tamat masa arahan tanpa memindahkan banyak data.

Tukar kepada kursor sebelah klien, atau naikkan saiz pengambilan dan kelompokkan baris, dan bilangan perjalanan pergi balik menurun. Halangan ialah bilangan pertukaran, bukan kelajuan pautan nominal, jadi mengukur daya pemprosesan akan mengelirukan anda manakala mengukur perjalanan tidak. Uji dengan set hasil terbesar yang benar-benar diambil pengguna anda, bukan dengan pertanyaan satu baris yang kembali serta-merta. Jika tamat masa berganjak tetapi tidak hilang, naikkan tamat masa arahan dan saiz pengambilan bersama-sama dan ukur semula.

Aritmetik yang sama terpakai kepada ORM yang banyak bercakap dan kepada mana-mana klien yang mengeluarkan satu pernyataan setiap baris. Jika pelan pertanyaan baik dan pemindahan kecil, kira pertukaran rangkaian sebelum menala pangkalan data.

Periksa port, instans dan penapis tempatan

Instans bernama mendengar pada port dinamik, jadi sahkan port dan bukannya menganggap 1433. Pada instans lalai nilainya boleh dibaca daripada nilai pendaftaran TcpPort di bawah kunci SuperSocketNetLib instans itu. Untuk Oracle, sahkan bahawa hos dalam tnsnames.ora diselesaikan, alamat menjawab dan port pendengar dibenarkan; 1521 ialah lalai biasa, bukan jaminan.

Kemudian ketepikan senarai akses terowong itu sendiri dan, akhirnya, antivirus tempatan atau tembok api hos yang menyekat sambungan walaupun klien dan pelayan berada pada mesin yang sama. Catat peringkat yang gagal sebelum menukar konfigurasi, kerana penyelesaian nama, ketercapaian TCP dan TLS atau log masuk masing-masing gagal dengan mesej berbeza.

Tulis peringkat itu dalam tiket. Jika tidak, orang seterusnya akan mengulang pencarian rentetan sambungan yang sama yang memulakan semua ini.