SQL sa ibabaw ng VPN: direktang kliyente o panloob na workstation?

Gusto ng mga koponan ng SSMS sa kanilang mga laptop, at ang mabilis na solusyon ay ilathala ang SQL port sa VPN pool. Ang mas mabagal na sagot ay nagtatanong kung saan dapat tumakbo ang proseso ng kliyente, dahil ang direktang pag-access at panloob na workstation ay gumagawa ng magkaibang source address, pagtitiwala sa endpoint at mga landas ng data. Wala sa dalawa ang awtomatikong ligtas, at ang pagiging miyembro ng VPN lamang ay walang pinagpapasyahan. Ihambing ang mga disenyo bago pa man umiiral ang isang tuntunin ng pahintulot.

Dalawang landas, dalawang source address

Sa direktang pag-access, dinadala ng laptop ang configuration ng kliyente at siya mismo ang nagbubukas ng koneksyon sa database. Sa isang remote na workstation, nagbubukas ang laptop ng desktop session, at ang workstation ang gumagawa ng SQL koneksyon mula sa sarili nitong address. Kaya nakikita ng database ang VPN pool o isang isinaling gateway sa unang disenyo, at ang address ng workstation sa pangalawa. Ang pagkakaibang iyon ang nagpapasya kung aling tuntunin ng firewall at aling pahintulot ng SQL ang tunay na nalalapat.

Kinokontrol pa rin ng laptop ang remote session, kaya ang workstation ay hindi kapalit ng authentication ng user o patakaran ng session.

Tingnan kung ano talaga ang nakikita ng database

Ang source address ay sinusukat, hindi hinuhulaan mula sa diagram. Basahin ito sa panig ng server ng isang aktibong koneksyon.

Test-NetConnection sql.example.com -Port 1433
sqlcmd -S tcp:sql.example.com,1433 -N -d appdb -Q "select SUSER_SNAME() as login_name, DB_NAME() as db"

Pinatutunayan ng test ng konektibidad na tinatanggap ng listener ang TCP mula sa network na iyon, habang pinatutunayan ng query kung aling login at database ang naabot ng session. Upang makita ang address na naitala ng server, tanungin ang sys.dm_exec_connections para sa kasalukuyang session, na nagbabalik ng address ng kliyente pagkatapos ng anumang pagsasalin. Kung ang halagang iyon ay gateway at hindi ang laptop, ang tuntunin ng host bawat user ay hindi maaaring gumana sa makina ng database. Isulat ang naobserbahang halaga sa tabi ng piniling disenyo, dahil ginagalaw ito ng mga muling koneksyon at pagbabago ng pool.

Buksan ang listener at wala nang iba

Buksan lamang ang serbisyo na kailangan ng deployment. Ang pamilyar na 1433 ay port ng default na instance, hindi isang unibersal na constant.

Get-NetTCPConnection -State Listen -LocalPort 1433

Ang mga pinangalanang instance ay madalas makinig sa isang dynamic na port, kung saan sinasagot ng SQL Server Browser ang pagtuklas sa UDP 1434, at ang pag-asa na iyon ay hiwalay na pagkakalantad na kailangang bigyang-katwiran. Ang pag-pin ng fixed na port para sa instance ay nag-aalis ng pangangailangan sa Browser at ginagawang matatag ang mga tuntunin ng firewall. Panatilihin ang mga pagsusuri sa encryption at certificate na ginagawa na ng kliyente sa halip na patayin ang mga ito upang pumasa ang isang test. Pagkatapos ay magbigay ng mga role ng database para sa workload sa halip na idagdag ang buong VPN group sa isang server role.

Patunayan ang pinapayagang landas at ang tinanggihan

Magbukas ng bagong session bilang ordinaryong aprubadong user, at kumpirmahin ang pagkakakilanlan ng server, ang database at ang kinakailangang operasyon. Pagkatapos ay kumpirmahin ang pagbubukod: ang pinagmulan o account sa labas ng patakaran ay dapat mabigo sa parehong test. Para sa disenyo ng workstation, tiyakin na hindi malalampasan ng laptop ang hangganan sa pamamagitan ng direktang pag-abot sa database. Para sa direktang pag-access, tiyakin na wasto pa rin ang ruta at tuntunin ng pinagmulan pagkatapos ng muling koneksyon.

Itala kung saan tumakbo ang kliyente, aling pinagmulan ang naobserbahan ng database at aling tuntunin ang nagpahintulot. Iyon ang ebidensiyang hihilingin ng susunod na pagsusuri.