Nē, savienojuma virkne nevar palaist jūsu VPN tuneli

Izstrādātāji joprojām meklē vietu, kur savienojuma virkne, JDBC URL vai tnsnames.ora ieraksts izvēlas VPN. Tādas vietas nav. Tuneli izveido operētājsistēma vai piegādātāja klients, kas reģistrē virtuālo adapteri, un katra datubāzes bibliotēka virs tā izmanto izrietošo ligzdas slāni. Savienojuma virkne nosauc resursdatoru, portu un akreditācijas datus, un tas ir viss vārdnīca.

Mīts: savienojuma virkne var izvēlēties tuneli

Draivers atver TCP ligzdu uz resursdatoru un portu. Tam nav API tuneļa pacelšanai, nav lauka tuneļa profilam un nav veida, kā autentificēties VPN vārtejā.

Tāpēc rīki uzvedas vienādi, tiklīdz maršruts pastāv. SSMS, DBeaver, Eclipse Data Tools un vienkāršs sqlcmd rīkojas tā, it kā serveris būtu vietējā tīklā, jo no ligzdas viedokļa tas tā arī ir. Virtuālais adapters padarīja datubāzes apakštīklu sasniedzamu, un draivers nekad nezina, kā.

Tas arī izskaidro, kāpēc savienojuma virkne nevar salabot pārrautu tuneli. Kad saite mirst, draivers ziņo par taimautu vai vispārīgu tīkla kļūdu, un lietojumprogrammas kods, kas to uzskata par vaicājuma problēmu, mūžīgi atkārto nepareizo slāni.

Paceliet tuneli pirms draivera palaišanas

Pieslēdzieties VPN operētājsistēmas līmenī, ievērojot pakalpojumu sniedzēja vai tīkla komandas norādes, un tikai pēc tam atveriet rīku. Praksē tas nozīmē, ka maršruts uz datubāzes apakštīklu pastāv pirms tam, kad draivers atrisina resursdatora nosaukumu.

Turiet tuneļa uzraudzību ārpus lietojumprogrammas. PHP vai Java pakalpojums, kas pats mēģina pacelt saiti, iekodē viena pakalpojumu sniedzēja uzvedību biznesa kodā, un katra atteices pāreja kļūst par lietojumprogrammas laidienu. Uzraugs, kuram pieder tunelis, kas to novēro un restartē, ir atsevišķs jautājums no vaicājuma ceļa.

Pārbaudiet maršrutu, pirms vainot draiveri: ja resursdators neatrisinās vai ports neatbild no čaulas, neviena savienojuma virkne to nemainīs.

Mīts: Windows autentifikācijas kļūda nozīmē, ka maršruts ir salauzts

Windows autentifikācija caur VPN bieži neizdodas ar kļūdu, kas izskatās pēc tīkla bojājuma, un maršruts ir kārtībā. Kad konts pieder citam domēnam un klēpjdators tam nevar pievienoties, palaidiet klientu ar skaidriem akreditācijas datiem, nevis ar darbvirsmas sesijas identitāti.

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

/netonly slēdzis saglabā šos datus tikai attālinātai autentifikācijai. Pārbaudiet, ko serveris faktiski saņēma, ar SELECT SUSER_SNAME(), nevis uzticoties savienojuma dialoglodziņam. Tiek ziņots, ka servera adreses akreditācijas datu glabāšana Windows Credential Manager darbojas SSMS, bet ne vienmēr pakalpojumam, kas darbojas citā kontā, tāpēc pirms pieteikšanās maiņas pārbaudiet, kādu identitāti process izmanto.

Aizture pārvērš servera puses kursoru taimautā

Servera puses kursors lūdz datubāzei turēt rezultātu un iegūt to pakāpeniski, kas vienu lielu rezultātu pārvērš daudzos mazos turp un atpakaļ braucienos. Lokālajā tīklā tas ir lēti. Caur tuneli ar desmitiem milisekundes papildu aiztures tas pats vaicājums var pārsniegt komandas taimautu, gandrīz neko nenododot.

Pārejiet uz klienta puses kursoru vai palieliniet iegūšanas izmēru un sagrupējiet rindas, un turp un atpakaļ braucienu skaits samazinās. Šaurā vieta ir apmaiņu skaits, nevis saites nominālais ātrums, tāpēc caurlaidspējas mērīšana jūs maldinās, bet braucienu mērīšana ne. Pārbaudiet ar lielāko rezultātu kopu, ko jūsu lietotāji patiešām velk, nevis ar vienas rindas vaicājumu, kas atgriežas acumirklī. Ja taimauts pārvietojas, bet nepazūd, palieliniet komandas taimautu un iegūšanas izmēru kopā un mēriet vēlreiz.

Tā pati aritmētika attiecas uz runīgiem ORM un jebkuru klientu, kas izdod vienu priekšrakstu uz rindu. Ja vaicājuma plāns ir labs un pārsūtīšana maza, saskaitiet tīkla apmaiņas pirms datubāzes regulēšanas.

Pārbaudiet portu, instanci un vietējo filtru

Nosaukta instance klausās dinamiskā portā, tāpēc apstipriniet portu, nevis pieņemiet 1433. Noklusējuma instancē vērtību var nolasīt no TcpPort reģistra vērtības zem instances SuperSocketNetLib atslēgas. Oracle gadījumā pārbaudiet, vai resursdators tnsnames.ora tiek atrisināts, vai adrese atbild un vai klausītāja ports ir atļauts; 1521 ir izplatīta noklusējuma vērtība, nevis garantija.

Pēc tam izslēdziet paša tuneļa piekļuves sarakstu un visbeidzot vietējo antivīrusu vai resursdatora ugunsmūri, kas bloķē savienojumu pat tad, ja klients un serveris ir viena un tā pati mašīna. Fiksējiet neizdevušos posmu pirms konfigurācijas maiņas, jo nosaukumu atrisināšana, TCP sasniedzamība un TLS vai pieteikšanās katrs neizdodas ar citu ziņojumu.

Ierakstiet posmu biļetē. Citādi nākamais cilvēks atkārtos to pašu savienojuma virknes meklēšanu, ar ko viss sākās.