SQL Server se váže na adresu VPN, která při startu neexistuje

Přečtěte si řádek protokolu SQL Serveru o neúspěšném navázání, zatímco služba stále běží, a našli jste závislost na pořadí startu, nikoli pád. Právě tato kombinace je stopa: stroj se spustil dřív, než na něm existovala adresa, na které měl poslouchat. VPN adaptér, který se objeví až po přihlášení, je špatný předpoklad pro databázovou službu bez dohledu, proto projděte selhání v pořadí, v jakém ho stroj vidí.

Začněte u startovacího protokolu, ne u klienta

Otevřete protokol chyb instance a přečtěte si záznamy kolem inicializace sítě, ne jen poslední řádek. Stroj uvádí, které adresy zkoušel a které protokoly povolil, a tento záznam je z doby před připojením jakéhokoli klienta. Teď se podívejte, co na hostiteli existuje právě teď. Pokud se rozhraní, které vlastní nakonfigurovanou adresu, objeví až poté, co se uživatel přihlásí a spustí klienta, adresa při startu chyběla a selhání navázání je plně vysvětleno.

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

Upravte cestu instance podle své instalace a přečtěte si seznam rozhraní, než vyvodíte závěry. Adresa, která existuje, ale patří špatnému adaptéru, je jiný problém než adresa, která ještě neexistuje.

Projděte pořadí navázání, které stroj skutečně dodržuje

Stroj přečte konfiguraci listeneru a potom požádá operační systém o navázání. Pokud adresa v tu chvíli není lokální, navázání pro tuto adresu selže, zatímco zbytek instance může pokračovat normálně. Proto mohou jiné protokoly nebo jiné adresy stále fungovat a proto je „SQL Server je mimo provoz“ špatné shrnutí. Zachovejte přesný koncový bod z protokolu: adresu, port a protokol, protože oprava závisí na tom, které z těch tří je špatně.

Restart služby poté, co se adaptér objeví, obvykle zajistí úspěch listeneru, a to je právě past. Dokazuje závislost, místo aby ji odstranil, a přeruší každého připojeného uživatele při každém opětovném připojení tunelu.

Čtěte listener tak, jak ho čte stroj

V SQL Server Configuration Manager otevřete vlastnosti TCP/IP instance a před úpravou jednotlivých adres si všimněte nastavení Listen All. Když je Listen All nastaveno na Yes, hodnoty Enabled pro jednotlivé adresy se ignorují, takže jejich úprava nemění nic, co listener používá. Zaznamenejte tři věci v pořadí: adresu, kterou chcete obsluhovat, port a zda má listener pokrývat všechny adresy, nebo jen jednu. Potom změnu použijte podporovaným postupem restartu a přečtěte si další startovací protokol, abyste potvrdili, že stroj navázal to, o co jste žádali.

Naslouchání na všech adresách není řízení přístupu. Pokud je široký listener skutečně potřeba, každé dostupné rozhraní potřebuje vlastní rozhodnutí o firewallu a autorizaci databáze, včetně jakéhokoli rozhraní obráceného do internetu.

Dejte klientovi stabilní cíl

Klient nepotřebuje, aby hostitel databáze nosil adresu z poolu. Směrované řešení funguje tak, že server naslouchá na své stabilní privátní adrese, zatímco VPN brána přeposílá provoz klienta k němu a nese odpověď zpět.

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

Pokud se klient dostane na 10.80.0.15, cesta je prokázaná a databáze musí jen autorizovat tohoto klienta. Pokud ne, opravte směrování a DNS, než se znovu dotknete listeneru, protože problém navázání na serveru nikdy nebyl důvodem, proč ho klient nemůže najít. Přidání falešné adresy z poolu na server nebo druhé výchozí brány, aby byl listener spokojený, vytváří nový síťový problém navrch starého. Udržujte adresování serveru statické a nechte tunel přivádět klienty k němu.

Ověřte koncový bod, který klient použil

Skončete kontrolou na úrovni aplikace, ne testem portu. Připojte se z klienta účtem, který aplikace používá, a přečtěte si podrobnosti připojení na straně serveru, které ukazují lokální adresu, na kterou vaše relace dosedla.

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"

Porovnejte tuto adresu s listenerem, který jste nakonfigurovali. Nesoulad znamená druhý listener nebo jméno, které se překládá někde nečekaně, a obojí stojí za to vědět, než příští restart otestuje vaši opravu za vás. Potom restartujte hostitele bez přihlášeného uživatele a potvrďte, že navázání uspěje. Ten jediný test je rozdíl mezi opraveným listenerem a obchvatem, který selže příští patchovací noc.