SQL kupitia VPN: mteja wa moja kwa moja au kituo cha kazi cha ndani?

Timu zinataka SSMS kwenye kompyuta zao za mkononi, na suluhisho la haraka ni kuchapisha mlango wa SQL kwenye bwawa la VPN. Jibu la polepole zaidi linauliza mchakato wa mteja unapaswa kuendeshwa wapi, kwa sababu ufikiaji wa moja kwa moja na kituo cha kazi cha ndani huzalisha anwani tofauti za chanzo, uaminifu wa kiishilio na njia za data tofauti. Hakuna hata moja iliyo salama kiotomatiki, na uanachama wa VPN peke yake hauamua chochote. Linganisha miundo kabla ya sheria ya ruhusa kuwepo.

Njia mbili, anwani mbili za chanzo

Katika ufikiaji wa moja kwa moja kompyuta ya mkononi hubeba usanidi wa mteja na hufungua muunganisho wa hifadhidata yenyewe. Kwenye kituo cha kazi cha mbali kompyuta hufungua kikao cha eneo-kazi, na kituo cha kazi hufanya muunganisho wa SQL kutoka anwani yake. Kwa hiyo hifadhidata huona bwawa la VPN au lango lililotafsiriwa katika muundo wa kwanza, na anwani ya kituo cha kazi katika wa pili. Tofauti hiyo ndiyo huamua sheria gani ya firewall na ruhusa gani ya SQL inatumika kwa kweli.

Kompyuta ya mkononi bado inadhibiti kikao cha mbali, kwa hiyo kituo cha kazi hakichukui nafasi ya uthibitishaji wa mtumiaji au sera ya kikao.

Angalia kile hifadhidata inachokiona kwa kweli

Anwani ya chanzo ni kitu cha kupimwa badala ya kukisiwa kutoka kwenye mchoro. Isome kutoka upande wa seva wa muunganisho hai.

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"

Jaribio la muunganisho linathibitisha kwamba msikilizaji hukubali TCP kutoka mtandao huo, wakati swali linathibitisha ni kuingia gani na hifadhidata gani kikao kilifika. Ili kuona anwani ambayo seva ilirekodi, uliza sys.dm_exec_connections kwa kikao cha sasa, ambayo hurudisha anwani ya mteja baada ya tafsiri yoyote. Ikiwa thamani hiyo ni lango na si kompyuta ya mkononi, sheria ya mwenyeji kwa kila mtumiaji haiwezi kufanya kazi kwenye mashine ya hifadhidata. Andika thamani iliyozingatiwa kando ya muundo uliochaguliwa, kwa sababu muunganisho upya na mabadiliko ya bwawa huihamisha.

Fungua msikilizaji na hakuna kingine

Fungua huduma ambayo usambazaji unahitaji pekee. 1433 inayojulikana ni mlango wa mfano chaguo-msingi, si thabiti ya ulimwengu wote.

Get-NetTCPConnection -State Listen -LocalPort 1433

Mifano yenye majina mara nyingi husikiliza kwenye mlango unaobadilika, SQL Server Browser hujibu ugunduzi kwenye UDP 1434, na utegemezi huo ni mfiduo tofauti unaohitaji kuhesabiwa haki. Kubandika mlango thabiti kwa mfano huondoa hitaji la Browser na hufanya sheria za firewall kuwa thabiti. Weka ukaguzi wa usimbaji fiche na cheti ambao mteja tayari hufanya badala ya kuzizima ili jaribio lipite. Kisha toa majukumu ya hifadhidata kwa mzigo wa kazi badala ya kuongeza kundi lote la VPN kwenye jukumu la seva.

Thibitisha njia iliyoruhusiwa na iliyokataliwa

Fungua kikao kipya kama mtumiaji wa kawaida aliyekubaliwa, na thibitisha utambulisho wa seva, hifadhidata na operesheni inayohitajika. Kisha thibitisha ubaguzi: chanzo au akaunti nje ya sera lazima ishindwe katika jaribio hilo hilo. Kwa muundo wa kituo cha kazi, thibitisha kuwa kompyuta ya mkononi haiwezi kukwepa mpaka kwa kufikia hifadhidata moja kwa moja. Kwa ufikiaji wa moja kwa moja, thibitisha kuwa njia na sheria ya chanzo bado zinatumika baada ya muunganisho upya.

Rekodi mahali mteja alikimbia, chanzo gani hifadhidata ilizingatia na sheria gani iliruhusu. Hiyo ndiyo ushahidi ambao ukaguzi ujao utautaka.