Kielekezi kilichotajwa cha SQL Server kupitia VPN: ugunduzi, si lango 1433

Watu wengi huchukulia jina la mwenyeji la SQL Server kama anwani kamili, na VPN kama kitu kinachoruhusiwa au la. Kivitendo kielekezi kilichotajwa humfanya mteja kufanya utafutaji wa pili baada ya DNS, na utafutaji huo ndio sehemu ambayo handaki huvunja mara nyingi. Kituo cha mwisho kilicho wazi hukwepa hilo, ndiyo sababu tcp:host,port inaweza kufanya kazi wakati host\INSTANCE inaisha muda. Tofauti ni kati ya kupata huduma na kupata ruhusa ya kuitumia.

Hadithi: jina moja la mwenyeji humaanisha lango moja

Jina la mwenyeji hutatuliwa kuwa anwani, na hapo kazi yake inaisha. Kielekezi kilichotajwa huongeza jina la kielekezi ambalo seva inapaswa kulitafsiri kuwa lango la TCP, na mteja hawezi kulikisia. Lango 1433 ni chaguo-msingi kwa kielekezi cha chaguo-msingi, si sifa ya kila kielekezi kwenye mashine. Kuchukulia vyote viwili kama kitu kimoja huzalisha dalili ya kawaida: ping inafanya kazi, DNS inafanya kazi, uchunguzi wa 1433 hauonyeshi chochote, na hitimisho ni kwamba mtandao unazuia SQL.

Dhana ya pili inashindikana vivyo hivyo: kwamba kufungua TCP 1433 kunatosha. Ikiwa kielekezi kinasikiliza mahali pengine, 1433 iliyofunguliwa inathibitisha tu kwamba kuna kitu kingine hapo. Lango linapaswa kuendana na msikilizaji, na kwamba msikilizaji ni maelezo ya usanidi upande wa seva hilo linapaswa kuulizwa badala ya kudhaniwa.

Mteja hufanya nini kwa kweli na kielekezi kilichotajwa

Baada ya kutatua mwenyeji, mteja hutuma ombi la ugunduzi kwa SQL Browser kupitia UDP 1434 na kuuliza ni lango gani kielekezi kilichotajwa kinatumia. Huduma ya kivinjari hujibu kutoka rejista ya seva yenyewe, kisha mteja hufungua muunganisho wa TCP kwa lango hilo. Itifaki mbili na malango mawili yanahusika kabla ya kujaribu kuingia.

nslookup sqlhost.corp.example
nc -vzu sqlhost.corp.example 1434
Get-Service -Name SQLBrowser

Ndiyo sababu kuzuia UDP pekee huzalisha muda wa kumalizika unaoonekana kama mwenyeji aliyekufa. Ikiwa huduma ya kivinjari imesimamishwa au imezimwa, ombi la ugunduzi linabaki bila jibu ingawa injini ya hifadhidata inafanya kazi na lango lake la TCP limefunguliwa. Ikiwa kielekezi kimesanidiwa na lango thabiti, mteja bado anauliza isipokuwa amepewa kituo cha mwisho moja kwa moja. Kila moja ya hitilafu hizi inaonekana sawa katika ujumbe wa hitilafu wa programu, na zinahitaji marekebisho tofauti.

Huduma ya kivinjari ni urahisi wa ugunduzi, si hifadhidata. Kuisimamisha hakuisimamishi injini, na kuiwasha hakufungui lango la TCP la kielekezi.

Kwa nini kituo cha mwisho kilicho wazi hufanya kazi wakati jina halifanyi kazi

Kituo cha mwisho kilicho wazi huondoa utafutaji kutoka kwa mfuatano: mteja huunganisha moja kwa moja na anwani na lango ulizotaja. Hii kwanza ni uchunguzi, si marekebisho ya kudumu kiotomatiki, kwa sababu lango linaweza kubadilika ikiwa kielekezi kitasanidiwa upya kuwa la kubadilika baadaye. Linganisha aina mbili kwa mteja yuleyule na akaunti ileile kabla ya kufikia hitimisho.

sqlcmd -S "tcp:sqlhost.corp.example,51433" -U app_login -Q "SELECT @@SERVERNAME"
Test-NetConnection sqlhost.corp.example -Port 51433

Ikiwa aina ya wazi inafanikiwa na aina iliyotajwa inashindikana, ugunduzi ndio pengo, na unaweza kuchagua jinsi ya kulifunga: ruhusu UDP 1434 kupitia handaki, au mwombe msimamizi kubainisha lango thabiti na kuandika kituo cha mwisho. Zote mbili ni maamuzi ya makusudi yenye gharama tofauti za matengenezo. Kufungua kila lango katika masafa si mojawapo, na ndiyo chaguo ambalo hupendekezwa mwishoni mwa siku ndefu. Rekodi chaguo mahali ambapo mifuatano ya muunganisho inaishi.

Ikiwa hakuna aina inayofanya kazi, tatizo liko juu ya ugunduzi. Angalia msikilizaji, njia na kanuni ya ufikiaji kwa lango ambalo kielekezi kinatumia kwa kweli kabla ya kulaumu huduma ya kivinjari.

Baada ya ugunduzi: uthibitishaji na utambulisho ni tofauti

Kushindikana kwa kuingia ni tukio tofauti na muda wa kumalizika, na utambulisho wa VPN haubadiliki kuwa kuingia kwa SQL kwa sababu ya handaki. Mteja anapofikia lango sahihi, injini ya hifadhidata hutumia uthibitishaji wake na ruhusa zake. Kuchanganya hatua mbili katika tikiti moja ndiyo njia ambayo tatizo la ugunduzi hupewa timu isiyofaa. Soma namba ya hitilafu kabla ya kubadilisha chochote.

Hifadhi jina la mwenyeji lililoandikwa ikiwa dereva huthibitisha cheti cha seva, kwa sababu kuunganisha kwa anwani ya namba kunaweza kubadilisha ukaguzi huo badala ya kutatua tatizo la awali. Madereva mapya ya Microsoft husimba kwa chaguo-msingi, hivyo kutokupatana kwa jina huonekana kama hitilafu ya cheti baada ya muunganisho wa TCP kufanikiwa. Hiyo ni maendeleo si kushindikana mpya.

Hadithi inayopaswa kuachwa ni kwamba jina la mwenyeji la SQL Server ni anwani kamili. Ni mwenyeji pamoja na, kwa kielekezi kilichotajwa, utafutaji ambao handaki huenda usiubebe. Taja lango, taja njia ya ugunduzi, na kushindikana kunakofuata kutakuambia tabaka gani la kurekebisha.