SQL Server inafungamana na anwani ya VPN ambayo haipo wakati wa kuwasha

Soma mstari wa kumbukumbu ya SQL Server kuhusu muunganisho ulioshindikana wakati huduma bado inaendelea, na umepata utegemezi wa mpangilio wa kuwasha, si kuanguka. Mchanganyiko huo ndio kidokezo: injini ilianza kabla anwani iliyoambiwa isikilize haipo kwenye mashine. Adapta ya VPN inayojitokeza baada ya kuingia ni sharti dhaifu kwa huduma ya hifadhidata isiyosimamiwa, kwa hivyo fuatilia hitilafu kwa mpangilio ambao injini inaiona.

Anza kwenye kumbukumbu ya kuanza, si kwa mteja

Fungua kumbukumbu ya makosa ya kisa na usome maingizo karibu na uanzishaji wa mtandao, si mstari wa mwisho pekee. Injini huripoti ni anwani gani ilijaribu na itifaki gani iliwezesha, na rekodi hiyo ni ya kabla mteja yeyote kuunganisha. Sasa angalia kilichopo kwenye mwenyeji kwa sasa. Ikiwa kiolesura kinachomiliki anwani iliyosanidiwa kinaonekana tu baada ya mtumiaji kuingia na kuanzisha mteja, anwani haikuwepo wakati wa kuwasha na hitilafu ya muunganisho imeelezwa kikamilifu.

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixOrigin
Get-Content 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\LOG\ERRORLOG' -Tail 40

Rekebisha njia ya kisa kulingana na usakinishaji wako, na usome orodha ya violesura kabla ya kufikia hitimisho. Anwani iliyopo lakini inayomilikiwa na adapta isiyo sahihi ni tatizo tofauti na anwani ambayo bado haipo.

Pitia mpangilio wa muunganisho ambao injini hufuata kwa kweli

Injini husoma usanidi wake wa msikilizaji kisha huomba mfumo wa uendeshaji kufungamanisha. Ikiwa anwani si ya ndani wakati huo, muunganisho unashindikana kwa anwani hiyo huku sehemu nyingine ya kisa ikiweza kuendelea kawaida. Ndiyo sababu itifaki nyingine au anwani nyingine zinaweza bado kufanya kazi, na ndiyo sababu „SQL Server imeanguka“ ni muhtasari usio sahihi. Hifadhi kituo kamili cha mwisho kutoka kumbukumbu: anwani, lango na itifaki, kwa sababu marekebisho yanategemea ipi kati ya hizo tatu si sahihi.

Kuanzisha upya huduma baada ya adapta kuonekana kwa kawaida kutafanya msikilizaji afanikiwe, na hiyo ndiyo mtego hasa. Inathibitisha utegemezi badala ya kuuondoa, na inakata kila mtumiaji aliyeunganishwa kila mara handaki inapounganisha tena.

Soma msikilizaji jinsi injini inavyousoma

Katika SQL Server Configuration Manager, fungua sifa za TCP/IP za kisa na uangalie mpangilio wa Listen All kabla ya kuhariri anwani binafsi. Listen All inapokuwa Yes, thamani za Enabled kwa kila anwani zinapuuzwa, kwa hivyo kuzihariri hakubadilishi chochote kinachotumiwa na msikilizaji. Andika mambo matatu kwa mpangilio: anwani unayokusudia kuhudumia, lango, na ikiwa msikilizaji anapaswa kugharamia anwani zote au moja tu. Kisha tumia badiliko kupitia utaratibu wa kuanzisha upya unaotumika na usome kumbukumbu inayofuata ya kuanza ili kuthibitisha injini ilifungamanisha ulichoomba.

Kusikiliza kwenye kila anwani si udhibiti wa ufikiaji. Ikiwa msikilizaji mpana unahitajika kweli, kila kiolesura kinachofikiwa kinahitaji uamuzi wake wa ngome na idhini ya hifadhidata, ikiwa ni pamoja na kiolesura chochote kinachoelekea mtandao.

Mpe mteja mwisho thabiti

Mteja hahitaji mwenyeji wa hifadhidata kuvaa anwani ya dimbwi. Muundo ulioelekezwa hufanya kazi huku seva ikisikiliza kwenye anwani yake thabiti ya faragha na lango la VPN likielekeza trafiki ya mteja kwake na kurudisha jibu.

Test-NetConnection -ComputerName 10.80.0.15 -Port 1433
tracert -d 10.80.0.15

Ikiwa mteja anafikia 10.80.0.15, njia imethibitika na hifadhidata inapaswa tu kuidhinisha mteja huyo. Ikiwa haifikii, rekebisha uelekezaji na DNS kabla ya kugusa msikilizaji tena, kwa sababu tatizo la muunganisho kwenye seva halikuwa kamwe sababu ya mteja kushindwa kuipata. Kuongeza anwani ya dimbwi ya uongo kwenye seva, au lango la pili la chaguo-msingi ili kumfurahisha msikilizaji, huunda tatizo jipya la mtandao juu ya lile la zamani. Weka anwani za seva zisizobadilika na uache handaki iwalete wateja kwake.

Thibitisha kituo cha mwisho ambacho mteja alitumia

Maliza kwa ukaguzi wa kiwango cha programu badala ya jaribio la lango. Unganisha kutoka kwa mteja kwa akaunti ambayo programu inatumia na usome maelezo ya muunganisho upande wa seva, ambayo yanaonyesha anwani ya ndani ambayo kikao chako kilitua.

sqlcmd -S tcp:10.80.0.15,1433 -Q "SELECT local_net_address, local_tcp_port FROM sys.dm_exec_connections WHERE session_id = @@SPID"

Linganisha anwani hiyo na msikilizaji uliosanidi. Kutolingana kunamaanisha msikilizaji wa pili au jina linalotatuliwa mahali pasipotarajiwa, na zote mbili zinafaa kujulikana kabla ya kuwasha upya kunakofuata kujaribu marekebisho yako badala yako. Kisha anzisha upya mwenyeji bila mtumiaji aliyeingia na uthibitishe kuwa muunganisho umefanikiwa. Jaribio hilo moja ndilo tofauti kati ya msikilizaji uliorekebishwa na suluhisho la muda linaloshindikana usiku ujao wa viraka.