Hindi, hindi kayang simulan ng connection string ang iyong VPN tunnel

Patuloy pang hinahanap ng mga developer ang lugar kung saan pinipili ng connection string, JDBC URL o entry sa tnsnames.ora ang VPN. Wala talagang ganoong lugar. Ang tunnel ay itinatayo ng operating system o ng client ng vendor na nagrerehistro ng virtual adapter, at bawat library ng database sa itaas nito ay gumagamit ng socket layer na resulta. Ang connection string ay nagpapangalan ng host, port at kredensyal, at iyon na ang buong bokabularyo.

Mito: kayang pumili ng tunnel ng connection string

Binubuksan ng driver ang TCP socket papunta sa host at port. Wala itong API para itaas ang tunnel, walang field para sa tunnel profile at walang paraan para magpatotoo sa isang VPN gateway.

Kaya ganoon din ang ugali ng mga tool kapag may ruta na. Ang SSMS, DBeaver, Eclipse Data Tools at ordinaryong sqlcmd ay kumikilos na parang nasa lokal na network ang server, dahil mula sa pananaw ng socket ay ganoon nga. Ginawang maabot ng virtual adapter ang subnet ng database, at hindi alam ng driver kung paano.

Ipinapaliwanag din nito kung bakit hindi kayang ayusin ng connection string ang tulang tunnel. Kapag namatay ang link, nag-uulat ang driver ng timeout o pangkalahatang error sa network, at ang code ng application na itinuturing itong problema sa query ay paulit-ulit na sinusubukan ang maling layer.

Itaas ang tunnel bago tumakbo ang driver

Ikonekta ang VPN sa antas ng operating system, ayon sa mga tagubilin ng provider o ng network team, at pagkatapos lamang buksan ang tool. Sa pagsasanay, nangangahulugan itong may ruta patungo sa subnet ng database bago i-resolve ng driver ang pangalan ng host.

Panatilihin ang pangangasiwa ng tunnel sa labas ng application. Ang serbisyong PHP o Java na kusang nagtatangkang itaas ang link ay naglalagay ng ugali ng isang provider sa business code, at bawat failover ay nagiging release ng application. Ang supervisor na nagmamay-ari ng tunnel, nagmamatyag at nag-restart nito ay hiwalay na usapin sa landas ng query.

Suriin ang ruta bago sisihin ang driver: kung hindi nagre-resolve ang host o hindi sumasagot ang port mula sa shell, walang connection string ang makakabago niyon.

Mito: ang pagkabigo ng authentication sa Windows ay nangangahulugang sira ang ruta

Ang authentication ng Windows sa VPN ay madalas nabibigo sa error na parang sira ng network, habang maayos naman ang ruta. Kapag kabilang ang account sa ibang domain at hindi ito kayang salihan ng laptop, simulan ang client gamit ang tahasang kredensyal sa halip na ang pagkakakilanlan ng desktop session.

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

/netonly switch ay itinatago ang mga kredensyal na iyon para sa malayuang authentication lamang. Tiyakin sa SELECT SUSER_SNAME() kung ano talaga ang natanggap ng server sa halip na magtiwala sa dialog ng koneksyon. Iniulat na gumagana sa SSMS ang pag-iimbak ng kredensyal para sa address ng server sa Windows Credential Manager ngunit hindi laging gumagana para sa serbisyong tumatakbo sa ibang account, kaya suriin kung anong pagkakakilanlan ang ginagamit ng proseso bago baguhin ang login.

Ang latency ay ginagawang timeout ang cursor sa panig ng server

Hinihiling ng cursor sa panig ng server na itago ng database ang resulta at isauli ito nang paunti-unti, na ginagawang maraming maliliit na paglalakbay pabalik-balik ang isang malaking resulta. Sa LAN, mura iyon. Sa tunnel na may dagdag na sampung millisecond na latency, ang parehong query ay maaaring lumampas sa timeout ng command nang halos walang naipadalang data.

Lumipat sa cursor sa panig ng client, o taasan ang laki ng pagkuha at pagsama-samahin ang mga hilera, at bumababa ang bilang ng paglalakbay. Ang bottleneck ay ang bilang ng palitan, hindi ang nominal na bilis ng link, kaya ang pagsukat ng throughput ay magliligaw sa iyo samantalang ang pagsukat ng paglalakbay ay hindi. Subukan gamit ang pinakamalaking set ng resulta na talagang kinukuha ng iyong mga user, hindi sa query na isang hilera na agad bumabalik. Kung gumagalaw ang timeout pero hindi nawawala, taasan nang sabay ang timeout ng command at ang laki ng pagkuha at sukatin muli.

Ang parehong aritmetika ay nalalapat sa mga pasalitang ORM at sa anumang client na naglalabas ng isang pahayag bawat hilera. Kung maayos ang plano ng query at maliit ang paglilipat, bilangin ang mga palitan sa network bago i-tune ang database.

Suriin ang port, ang instance at ang lokal na filter

Ang pinangalanang instance ay nakikinig sa dynamic na port, kaya tiyakin ang port sa halip na ipagpalagay na 1433. Sa default na instance, mababasa ang halaga mula sa value ng TcpPort sa registry sa ilalim ng key na SuperSocketNetLib ng instance. Para sa Oracle, tiyakin na nagre-resolve ang host sa tnsnames.ora, sumasagot ang address at pinapayagan ang port ng listener; ang 1521 ay karaniwang default, hindi garantiya.

Pagkatapos, ibukod ang access list ng tunnel mismo at, sa huli, ang lokal na antivirus o host firewall na humaharang sa koneksyon kahit ang client at server ay isang makina lamang. Itala ang yugtong nabibigo bago baguhin ang configuration, dahil ang pag-resolve ng pangalan, pag-abot ng TCP at TLS o pag-login ay bawat isa ay nabibigo sa magkakaibang mensahe.

Isulat ang yugto sa ticket. Kung hindi, uulitin ng susunod na tao ang parehong paghahanap ng connection string na nagpasimula ng lahat.