Statyczne porty

Statyczne porty to ręcznie przypisane numery ułatwiające konfigurację reguł zapory dla instancji nazwanej.

Statyczny port a nazwana instancja SQL Server

W SQL Server określenie „statyczne porty” odnosi się do przypisania instancji konkretnego, niezmiennego numeru portu TCP, na którym silnik nasłuchuje połączeń klientów. Ma to szczególne znaczenie dla nazwanej instancji, ponieważ po instalacji SQL Server może korzystać z portów dynamicznych. W takim trybie numer portu może zostać wybrany ponownie podczas uruchamiania usługi, co utrudnia przygotowanie stałej reguły zapory sieciowej. Statyczny port eliminuje tę zmienność: administrator ustala numer, a klienci łączą się z instancją przez wskazany punkt końcowy.

Port jest właściwością konkretnej instancji silnika SQL Server, a nie samej nazwy komputera. Na jednym serwerze mogą działać instancja domyślna i jedna lub wiele instancji nazwanych. Każda instancja korzystająca z protokołu TCP musi mieć własną konfigurację nasłuchu, dlatego numery portów nie mogą kolidować na tym samym adresie IP. Przykładowo instancja nazwana może nasłuchiwać na porcie TCP 51433, ale sama liczba nie jest uniwersalnym numerem przypisanym do SQL Server. Jest to wartość wybrana dla danej instalacji i środowiska.

Gdzie ustawia się port TCP dla instancji

Konfigurację wykonuje się w SQL Server Configuration Manager, w sekcji właściwości protokołu TCP/IP odpowiedniej instancji. W zakładce „IP Addresses” znajdują się ustawienia dla poszczególnych adresów IP oraz sekcja „IPAll”. Jeżeli ma być używany port statyczny, pole „TCP Dynamic Ports” należy pozostawić puste, a w polu „TCP Port” wpisać ustalony numer, na przykład 51433. W środowisku z wieloma aktywnymi adresami trzeba sprawdzić, czy ustawienia nie są nadpisywane przez konfigurację konkretnego adresu IP. Decydujące jest to, jaki adres i port są faktycznie aktywne dla połączeń.

Po zmianie ustawień protokołu TCP/IP należy ponownie uruchomić usługę odpowiedniej instancji SQL Server, ponieważ sama edycja wartości nie przełącza działającego procesu na nowy port. Po restarcie można sprawdzić log błędów SQL Server, w którym silnik zapisuje informację o adresach i portach, na których rozpoczął nasłuchiwanie. Weryfikacja logu jest istotna, gdy konfiguracja zawiera wiele adresów IP albo gdy wcześniej ustawiono port dynamiczny. Jeżeli usługa nie może zająć wybranego portu, przyczyną może być konflikt z innym procesem lub nieprawidłowa konfiguracja interfejsu sieciowego.

Reguły zapory i sposób nawiązywania połączenia

Reguła zapory dla połączeń do silnika powinna zezwalać na ruch przychodzący TCP na konkretny port przypisany instancji, na przykład TCP 51433. Otwieranie całego zakresu portów nie jest potrzebne do obsługi samego połączenia z silnikiem i utrudnia kontrolę konfiguracji. Reguła musi obowiązywać w profilu sieciowym używanym przez komputer oraz obejmować właściwy interfejs i kierunek ruchu. Sama obecność procesu SQL Server na liście wyjątków nie zawsze odpowiada zamierzonemu modelowi, zwłaszcza gdy po zmianie konfiguracji portu reguła oparta na numerze portu nadal wskazuje starą wartość.

Klient może wskazać port bezpośrednio w adresie serwera, używając formatu nazwa_hosta,51433. Przecinek oddzielający nazwę hosta od numeru portu jest składnią używaną przez klienta SQL Server do bezpośredniego określenia portu TCP. W takim połączeniu klient nie musi ustalać portu na podstawie samej nazwy instancji. Jeżeli używany jest zapis zawierający nazwę instancji, na przykład nazwa_hosta\Ksiegowosc, klient może potrzebować usługi SQL Server Browser. SQL Server Browser używa UDP na porcie 1434 do udzielania informacji o portach instancji, ale nie zastępuje portu TCP silnika i nie zapewnia obsługi zapytań SQL.

Sprawdzenie konfiguracji po zmianie numeru

Test powinien obejmować kilka oddzielnych elementów: działanie usługi SQL Server, aktywne ustawienie protokołu TCP/IP, nasłuchiwanie na oczekiwanym porcie oraz dostępność tego portu przez zaporę. Z komputera klienckiego można użyć polecenia PowerShell Test-NetConnection nazwa_hosta -Port 51433. Wynik z wartością TcpTestSucceeded : True potwierdza możliwość ustanowienia połączenia TCP z podanym hostem i portem, ale nie potwierdza jeszcze poprawnego uwierzytelnienia ani dostępu do konkretnej bazy. Dalszy test należy wykonać przy użyciu klienta SQL Server z prawidłowymi danymi logowania i nazwą bazy.

Jeżeli test TCP kończy się niepowodzeniem, trzeba rozdzielić problem sieciowy od problemu konfiguracji SQL Server. Warto sprawdzić, czy klient łączy się z właściwym adresem DNS, czy port nie jest zajęty przez inny proces oraz czy SQL Server nasłuchuje na adresie osiągalnym z sieci klienta. Gdy połączenie przez nazwa_hosta,51433 działa, a połączenie przez nazwa_hosta\Ksiegowosc nie działa, problem może dotyczyć wykrywania instancji przez SQL Server Browser, a nie statycznego portu silnika. Przy zmianie numeru portu trzeba również zaktualizować konfiguracje klientów i reguły zapory, ponieważ wcześniejszy numer przestaje być właściwym adresem usługi.