Nee, in ferbiningstring kin dyn VPN-tunnel net starte

Untwikkelers sykje altyd noch it plak dêr't in ferbiningstring, in JDBC-URL of in tnsnames.ora-ynskriuwing de VPN kiest. Sa'n plak is der net. De tunnel wurdt oprjochte troch it bestjoeringssysteem of in kliïnt fan in leveransier dy't in firtuele adapter registrearret, en elke databankbibleteek dêrboppe brûkt de socketlaach dy't dêrút folget. In ferbiningstring neamt in host, in poarte en in beynskip, en dat is it hiele wurdskat.

Myt: de ferbiningstring kin in tunnel kieze

De stjoerder iepenet in TCP-socket nei in host en poarte. Hy hat gjin API om in tunnel op te setten, gjin fjild foar in tunnelprofyl en gjin wize om by in VPN-gateway te autentisearjen.

Dêrom dogge de helpmiddels itselde as der in rûte bestiet. SSMS, DBeaver, Eclipse Data Tools en in gewoane sqlcmd dogge as wie de tsjinner op it lokale netwurk, want út it eachpunt fan de socket is dat sa. De firtuele adapter makke it databanksubnet berikber, en de stjoerder wit nea hoe.

Dat ferklearret ek wêrom't in ferbiningstring in ôfbrutsen tunnel net reparearje kin. As de ferbining stjert, meldt de stjoerder in time-out of in algemiene netwurkflater, en applikaasjekoada dy't dat as in fraachprobleem behannelet, werhellet foar altyd de ferkearde laach.

Set de tunnel op foar't de stjoerder rint

Ferbine de VPN op bestjoeringssysteemnivo, neffens de ynstruksjes fan de leveransier of it netwurkteam, en iepenje earst dêrnei it helpmiddel. Yn 'e praktyk betsjut dat dat der in rûte nei it databanksubnet bestiet foar't de stjoerder de hostnamme oplost.

Hâld tafersjoch op de tunnel bûten de applikaasje. In PHP- of Java-tsjinst dy't sels de ferbining opsette wol, kodearret it hâlden en dragen fan ien leveransier yn saaklike koade, en elke failover wurdt in applikaasje-útjefte. In tafersjochhâlder dy't de tunnel besit, him folget en him opnij start, is in aparte saak fan it fraachpaad.

Kontrolearje de rûte foar't jo de stjoerder de skuld jouwe: as de host net oplost of de poarte net antwurdet fan de shell, sil gjin inkele ferbiningstring dat feroarje.

Myt: in Windows-autentikaasjeflater betsjut dat de rûte stikken is

Windows-autentikaasje oer in VPN mislit faak mei in flater dy't op in netwurkstoarring liket, wylst de rûte goed is. As it akkount by in oar domein heart en de laptop dêr net by kin, start de kliïnt dan mei eksplisite beynskippen yn stee fan de identiteit fan 'e burosesje.

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

De /netonly-skeakel bewarret dy beynskippen allinnich foar ferôf-autentikaasje. Befêstigje wat de tsjinner wirklik krige mei SELECT SUSER_SNAME() yn stee fan de ferbiningdialooch te fertrouwen. Der wurdt melden dat it bewarjen fan 'e beynskippen foar it tsjinneradres yn Windows Credential Manager foar SSMS wurket, mar net altyd foar in tsjinst dy't ûnder in oar akkount rint, dus kontrolearje hokker identiteit it proses brûkt foar't jo de oanmelding feroarje.

Latinsje makket fan in tsjinnerside-cursor in time-out

In tsjinnerside-cursor freget de databank it resultaat te hâlden en it stadichoan te heljen, wat ien grut resultaat yn in soad lytse retourritten feroaret. Op in LAN is dat goedkeap. Oer in tunnel mei tsientallen millisekonden ekstra latinsje kin deselde fraach de opdrachttime-out oergean sûnder folle data oer te dragen.

Stap oer op in kliïntside-cursor, of ferheegje de fetch-grutte en batch de rigen, en it oantal retourritten sakket. De knelpunt is it oantal útwikselingen, net de nominale ferbiningsfaasje, dus it mjitten fan trochstreaming sil jo misliede wylst it mjitten fan retourritten dat net sil. Test mei de grutste resultaatset dy't jo brûkers wirklik lûke, net mei in fraach fan ien rigel dy't daliks weromkomt. As de time-out ferpleatst mar net ferdwynt, ferheegje dan de opdrachttime-out en de fetch-grutte tagelyk en mjit opnij.

Deselde rekkenkunde jildt foar pratende ORM's en foar elke kliïnt dy't ien útspraak per rigel docht. As it fraachplan goed is en de oerdracht lyts, tel dan de netwurkútwikselingen foar't jo de databank ôfstimme.

Kontrolearje de poarte, de eksimplaar en it lokale filter

In neamd eksimplaar harket op in dynamyske poarte, dus befêstigje de poarte yn stee fan 1433 oan te nimmen. Op in standert eksimplaar kin de wearde lêzen wurde út 'e TcpPort-registerwearde ûnder de SuperSocketNetLib-kaai fan it eksimplaar. Foar Oracle, kontrolearje dat de host yn tnsnames.ora oplost, dat it adres antwurdet en dat de listener-poarte tastien is; 1521 is in gewoane standert, gjin garânsje.

Slút dan de eigen tagongslist fan 'e tunnel út en, ta beslút, in lokale antyfirus of host-firewall dy't de ferbining blokkearret sels as kliïnt en tsjinner deselde masine binne. Fêstigje it stadium dat mislit foar't jo konfiguraasje feroarje, want namme-oplossing, TCP-berikberens en TLS of oanmelding mislearje elk mei in oar berjocht.

Skriuw it stadium yn it ticket. Oars werhellet de folgjende persoan deselde syktocht nei de ferbiningstring dêr't alles mei begon.