SQL Server wiąże się z adresem VPN, którego nie ma przy starcie

Przeczytaj wiersz dziennika SQL Server o nieudanym powiązaniu, gdy usługa jeszcze działa, a znajdziesz zależność od kolejności startu, nie awarię. Właśnie ta kombinacja jest wskazówką: silnik wystartował, zanim adres, na którym miał nasłuchiwać, istniał na maszynie. Adapter VPN pojawiający się po zalogowaniu to zły warunek wstępny dla nienadzorowanej usługi bazy danych, więc prześledź awarię w kolejności, w jakiej widzi ją silnik.

Zacznij od dziennika startowego, nie od klienta

Otwórz dziennik błędów instancji i przeczytaj wpisy wokół inicjalizacji sieci, nie tylko ostatni wiersz. Silnik podaje, których adresów próbował i które protokoły włączył, a ten zapis pochodzi sprzed połączenia jakiegokolwiek klienta. Teraz sprawdź, co istnieje na hoście w tej chwili. Jeśli interfejs posiadający skonfigurowany adres pojawia się dopiero po zalogowaniu użytkownika i uruchomieniu klienta, adresu nie było przy starcie i błąd powiązania jest w pełni wyjaśniony.

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

Dostosuj ścieżkę instancji do swojej instalacji i przeczytaj listę interfejsów, zanim wyciągniesz wnioski. Adres, który istnieje, ale należy do niewłaściwego adaptera, to inny problem niż adres, którego jeszcze nie ma.

Przejdź kolejność powiązania, której silnik faktycznie przestrzega

Silnik odczytuje konfigurację nasłuchu, a następnie prosi system operacyjny o powiązanie. Jeśli adres nie jest w tym momencie lokalny, powiązanie dla tego adresu kończy się niepowodzeniem, podczas gdy reszta instancji może działać normalnie. Dlatego inne protokoły lub inne adresy mogą nadal działać i dlatego „SQL Server nie działa“ to błędne podsumowanie. Zachowaj dokładny punkt końcowy z dziennika: adres, port i protokół, bo poprawka zależy od tego, który z tych trzech jest błędny.

Ponowne uruchomienie usługi po pojawieniu się adaptera zwykle sprawi, że nasłuch zadziała, i to jest właśnie pułapka. Dowodzi zależności, zamiast ją usuwać, i odcina każdego połączonego użytkownika za każdym razem, gdy tunel ponownie się łączy.

Czytaj nasłuch tak, jak czyta go silnik

W SQL Server Configuration Manager otwórz właściwości TCP/IP instancji i przed edycją pojedynczych adresów zwróć uwagę na ustawienie Listen All. Gdy Listen All ma wartość Yes, wartości Enabled dla poszczególnych adresów są ignorowane, więc ich edycja nie zmienia niczego, czego używa nasłuch. Zapisz trzy rzeczy po kolei: adres, który zamierzasz obsługiwać, port oraz to, czy nasłuch ma obejmować wszystkie adresy, czy tylko jeden. Następnie zastosuj zmianę przez obsługiwaną procedurę ponownego uruchomienia i przeczytaj kolejny dziennik startowy, aby potwierdzić, że silnik powiązał to, o co prosiłeś.

Nasłuchiwanie na każdym adresie nie jest kontrolą dostępu. Jeśli szeroki nasłuch jest naprawdę potrzebny, każdy osiągalny interfejs potrzebuje własnej decyzji dotyczącej zapory i autoryzacji bazy danych, w tym każdego interfejsu skierowanego do internetu.

Daj klientowi stabilny cel

Klient nie potrzebuje, aby host bazy danych nosił adres z puli. Projekt trasowany działa, gdy serwer nasłuchuje na swoim stabilnym adresie prywatnym, a brama VPN przekazuje do niego ruch klienta i przynosi odpowiedź z powrotem.

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

Jeśli klient dociera do 10.80.0.15, ścieżka jest udowodniona i baza danych musi tylko autoryzować tego klienta. Jeśli nie, napraw routing i DNS, zanim ponownie dotkniesz nasłuchu, bo problem powiązania na serwerze nigdy nie był powodem, dla którego klient nie może go znaleźć. Dodanie fałszywego adresu z puli do serwera albo drugiej domyślnej bramy, aby zadowolić nasłuch, tworzy nowy problem sieciowy na starym. Utrzymuj adresację serwera statyczną i pozwól tunelowi dostarczać do niego klientów.

Zweryfikuj punkt końcowy, którego użył klient

Zakończ kontrolą na poziomie aplikacji, a nie testem portu. Połącz się z klienta kontem, którego używa aplikacja, i odczytaj szczegóły połączenia po stronie serwera, które pokazują adres lokalny, na którym wylądowała sesja.

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"

Porównaj ten adres ze skonfigurowanym nasłuchem. Rozbieżność oznacza drugi nasłuch lub nazwę rozwiązywaną w nieoczekiwanym miejscu, a oba warto znać, zanim następny restart przetestuje twoją poprawkę za ciebie. Następnie uruchom ponownie host bez zalogowanego użytkownika i potwierdź, że powiązanie się udaje. Ten jeden test to różnica między naprawionym nasłuchem a obejściem, które zawodzi w następną noc łatek.