SQL Server piesaista VPN adresei, kuras sāknēšanas laikā nepastāv

Izlasiet SQL Server žurnāla rindu par neveiksmīgu piesaisti, kamēr pakalpojums vēl darbojas, un jūs esat atraduši atkarību no sāknēšanas secības, nevis avāriju. Tieši šī kombinācija ir pavediens: dzinējs startēja pirms tam, kad mašīnā pastāvēja adrese, uz kuras tam bija jāklausās. VPN adapteris, kas parādās pēc pieteikšanās, ir slikts priekšnosacījums datu bāzes pakalpojumam bez uzraudzības, tāpēc sekojiet kļūmei tādā secībā, kādā to redz dzinējs.

Sāciet ar starta žurnālu, nevis ar klientu

Atveriet instances kļūdu žurnālu un lasiet ierakstus ap tīkla inicializāciju, ne tikai pēdējo rindu. Dzinējs ziņo, kuras adreses tas mēģināja un kurus protokolus iespējoja, un šis ieraksts ir no laika pirms jebkurš klients pievienojās. Tagad apskatiet, kas šobrīd pastāv resursdatorā. Ja saskarne, kurai pieder konfigurētā adrese, parādās tikai pēc tam, kad lietotājs piesakās un palaiž klientu, adreses sāknēšanas laikā nebija un piesaistes kļūme ir pilnībā izskaidrota.

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

Pielāgojiet instances ceļu savai instalācijai un izlasiet saskarņu sarakstu pirms secinājumu izdarīšanas. Adrese, kas pastāv, bet pieder nepareizajam adapterim, ir cita problēma nekā adrese, kuras vēl nav.

Izejiet piesaistes secību, kuru dzinējs faktiski ievēro

Dzinējs nolasa klausītāja konfigurāciju un pēc tam lūdz operētājsistēmu piesaistīt. Ja adrese tajā brīdī nav lokāla, piesaiste šai adresei neizdodas, kamēr pārējā instances daļa var turpināt normāli. Tāpēc citi protokoli vai citas adreses joprojām var darboties, un tāpēc „SQL Server ir izslēgts“ ir nepareizs kopsavilkums. Saglabājiet precīzu galapunktu no žurnāla: adresi, portu un protokolu, jo labojums ir atkarīgs no tā, kurš no trim ir nepareizs.

Pakalpojuma restartēšana pēc adaptera parādīšanās parasti liks klausītājam gūt panākumus, un tā ir tieši slazds. Tas pierāda atkarību, nevis to novērš, un pārtrauc katru pievienoto lietotāju katru reizi, kad tunelis atkārtoti pievienojas.

Lasiet klausītāju tā, kā to lasa dzinējs

SQL Server Configuration Manager atveriet instances TCP/IP rekvizītus un pirms atsevišķu adrešu rediģēšanas ievērojiet iestatījumu Listen All. Kad Listen All ir Yes, Enabled vērtības katrai adresei tiek ignorētas, tāpēc to rediģēšana nemaina neko, ko izmanto klausītājs. Pierakstiet trīs lietas pēc kārtas: adresi, kuru plānojat apkalpot, portu un to, vai klausītājam jāaptver visas adreses vai tikai viena. Pēc tam piemērojiet izmaiņas ar atbalstīto restartēšanas procedūru un izlasiet nākamo starta žurnālu, lai apstiprinātu, ka dzinējs ir piesaistījis to, ko jūs lūdzāt.

Klausīšanās visās adresēs nav piekļuves kontrole. Ja plašs klausītājs tiešām ir nepieciešams, katrai sasniedzamajai saskarnei nepieciešams savs ugunsmūra un datu bāzes autorizācijas lēmums, tostarp jebkurai saskarnei, kas vērsta pret internetu.

Dodiet klientam stabilu galamērķi

Klientam nav nepieciešams, lai datu bāzes resursdators valkātu pūla adresi. Maršrutēts risinājums darbojas, kad serveris klausās savā stabilajā privātajā adresē, bet VPN vārteja pārsūta klienta trafiku tam un atgriež atbildi.

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

Ja klients sasniedz 10.80.0.15, ceļš ir pierādīts un datu bāzei tikai jāautorizē šis klients. Ja nesasniedz, izlabojiet maršrutēšanu un DNS pirms klausītāja atkārtotas aiztikšanas, jo piesaistes problēma serverī nekad nav bijusi iemesls, kāpēc klients to nevar atrast. Viltus pūla adreses pievienošana serverim vai otras noklusējuma vārtejas pievienošana, lai klausītāju iepriecinātu, rada jaunu tīkla problēmu virs vecās. Turiet servera adresāciju statisku un ļaujiet tunelim atvest klientus pie tā.

Pārbaudiet galapunktu, ko klients izmantoja

Pabeidziet ar lietojumprogrammas līmeņa pārbaudi, nevis porta testu. Pievienojieties no klienta ar kontu, ko izmanto lietojumprogramma, un izlasiet savienojuma informāciju servera pusē, kas parāda lokālo adresi, kurā nolaidās jūsu sesija.

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"

Salīdziniet šo adresi ar konfigurēto klausītāju. Neatbilstība nozīmē otru klausītāju vai vārdu, kas tiek atrisināts negaidītā vietā, un abus ir vērts zināt, pirms nākamā restartēšana pārbauda jūsu labojumu jūsu vietā. Pēc tam restartējiet resursdatoru bez pieteikušā lietotāja un apstipriniet, ka piesaiste izdodas. Šis viens tests ir atšķirība starp salabotu klausītāju un apejas risinājumu, kas neizdodas nākamajā ielāpu naktī.