SQL Server sa viaže na adresu VPN, ktorá pri štarte neexistuje
Prejdite neúspešné naviazanie SQL Servera od štartovacieho protokolu k efektívnemu listeneru a potom dajte klientom stabilnú privátnu adresu namiesto adresy z VPN poolu.
Prečítajte si riadok v protokole SQL Servera o neúspešnom naviazaní, kým služba ešte beží, a našli ste závislosť od poradia štartu, nie pád. Práve táto kombinácia je stopa: stroj sa spustil skôr, než na ňom existovala adresa, na ktorej mal počúvať. VPN adaptér, ktorý sa objaví až po prihlásení, je zlý predpoklad pre databázovú službu bez dohľadu, preto prejdite zlyhanie v poradí, v akom ho stroj vidí.
Začnite pri štartovacom protokole, nie pri klientovi
Otvorte protokol chýb inštancie a prečítajte si záznamy okolo inicializácie siete, nielen posledný riadok. Stroj uvádza, ktoré adresy skúsil a ktoré protokoly povolil, a tento záznam je z času pred pripojením akéhokoľvek klienta. Teraz sa pozrite, čo na hostiteľovi existuje práve teraz. Ak sa rozhranie, ktoré vlastní nakonfigurovanú adresu, objaví až po tom, čo sa používateľ prihlási a spustí klienta, adresa pri štarte chýbala a zlyhanie naviazania je úplne vysvetlené.
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixOrigin
Get-Content 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\LOG\ERRORLOG' -Tail 40
Prispôsobte cestu inštancie svojej inštalácii a prečítajte si zoznam rozhraní, skôr než vyvodíte závery. Adresa, ktorá existuje, ale patrí nesprávnemu adaptéru, je iný problém než adresa, ktorá ešte neexistuje.
Prejdite poradie naviazania, ktoré stroj skutočne dodržiava
Stroj prečíta konfiguráciu listenera a potom požiada operačný systém o naviazanie. Ak adresa v tej chvíli nie je lokálna, naviazanie pre túto adresu zlyhá, zatiaľ čo zvyšok inštancie môže pokračovať normálne. Preto môžu iné protokoly alebo iné adresy stále fungovať a preto je „SQL Server je mimo prevádzky“ nesprávne zhrnutie. Zachovajte presný koncový bod z protokolu: adresu, port a protokol, pretože oprava závisí od toho, ktorý z tých troch je nesprávny.
Reštart služby po objavení adaptéra zvyčajne spôsobí úspech listenera, a to je práve pasca. Dokazuje závislosť namiesto toho, aby ju odstránil, a preruší každého pripojeného používateľa pri každom opätovnom pripojení tunela.
Čítajte listener tak, ako ho číta stroj
V SQL Server Configuration Manager otvorte vlastnosti TCP/IP inštancie a pred úpravou jednotlivých adries si všimnite nastavenie Listen All. Keď je Listen All nastavené na Yes, hodnoty Enabled pre jednotlivé adresy sa ignorujú, takže ich úprava nemení nič, čo listener používa. Zaznamenajte tri veci v poradí: adresu, ktorú chcete obsluhovať, port a či má listener pokrývať všetky adresy alebo iba jednu. Potom zmenu použite podporovaným postupom reštartu a prečítajte si ďalší štartovací protokol, aby ste potvrdili, že stroj naviazal to, o čo ste žiadali.
Počúvanie na všetkých adresách nie je riadenie prístupu. Ak je široký listener skutočne potrebný, každé dosiahnuteľné rozhranie potrebuje vlastné rozhodnutie o firewalle a autorizácii databázy, vrátane každého rozhrania obráteného do internetu.
Dajte klientovi stabilný cieľ
Klient nepotrebuje, aby hostiteľ databázy nosil adresu z poolu. Smerované riešenie funguje tak, že server počúva na svojej stabilnej privátnej adrese, zatiaľ čo VPN brána preposiela prevádzku klienta k nemu a nesie odpoveď späť.
Test-NetConnection -ComputerName 10.80.0.15 -Port 1433
tracert -d 10.80.0.15
Ak sa klient dostane na 10.80.0.15, cesta je preukázaná a databáza musí len autorizovať tohto klienta. Ak nie, opravte smerovanie a DNS, skôr než sa znova dotknete listenera, pretože problém naviazania na serveri nikdy nebol dôvodom, prečo ho klient nemôže nájsť. Pridanie falošnej adresy z poolu na server alebo druhej predvolenej brány, aby bol listener spokojný, vytvára nový sieťový problém navrch starého. Udržujte adresovanie servera statické a nechajte tunel privádzať klientov k nemu.
Overte koncový bod, ktorý klient použil
Skončite kontrolou na úrovni aplikácie, nie testom portu. Pripojte sa z klienta účtom, ktorý aplikácia používa, a prečítajte si podrobnosti pripojenia na strane servera, ktoré ukazujú lokálnu adresu, na ktorú vaša relácia pristála.
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"
Porovnajte túto adresu s listenerom, ktorý ste nakonfigurovali. Nesúlad znamená druhý listener alebo názov, ktorý sa prekladá niekde nečakane, a oboje stojí za to vedieť, skôr než ďalší reštart otestuje vašu opravu za vás. Potom reštartujte hostiteľa bez prihláseného používateľa a potvrďte, že naviazanie uspeje. Ten jediný test je rozdiel medzi opraveným listenerom a obchvatom, ktorý zlyhá v ďalšiu opravnú noc.