Port TCP 1433

Port TCP 1433 musi być otwarty w zaporze, by klienci mogli łączyć się z domyślną instancją SQL Server.

Rola portu TCP 1433 w SQL Server

Port TCP 1433 jest domyślnym portem nasłuchu dla domyślnej instancji Microsoft SQL Server. Klient aplikacji, narzędzie administracyjne lub sterownik bazodanowy może użyć tego portu do zestawienia połączenia TCP z usługą SQL Server działającą na określonym komputerze. Sam numer portu nie identyfikuje jednak dowolnej usługi SQL Server w każdej konfiguracji. Dotyczy przede wszystkim domyślnej instancji, której nazwa logiczna jest zwykle zapisywana jako MSSQLSERVER.

Otwarcie portu w zaporze jest tylko jednym z warunków komunikacji. Usługa SQL Server musi rzeczywiście nasłuchiwać na adresie IP serwera i porcie 1433, protokół TCP/IP musi być włączony w konfiguracji instancji, a klient musi znać prawidłową nazwę hosta lub adres IP. Jeżeli instancja została skonfigurowana na innym porcie, reguła dla TCP 1433 nie umożliwi połączenia, nawet gdy sama usługa działa poprawnie.

Jak SQL Server wykorzystuje połączenie TCP

Podczas łączenia klient wskazuje serwer oraz, zależnie od sposobu konfiguracji, port. Dla domyślnej instancji często wystarcza nazwa hosta, ponieważ sterownik próbuje użyć domyślnego portu TCP 1433. Można również podać port jawnie, stosując zapis w rodzaju nazwa-serwera,1433. Przecinek oddzielający nazwę hosta od numeru portu jest składnią używaną przez klienta SQL Server do wskazania numeru portu.

Zapora sieciowa powinna zezwalać na ruch przychodzący TCP kierowany do portu 1433 na komputerze, na którym działa SQL Server. Reguła może być ograniczona do konkretnych profili sieciowych, adresów źródłowych lub podsieci, o ile odpowiada to rzeczywistej topologii połączeń. Nie należy utożsamiać otwarcia portu z udanym logowaniem do bazy: po przejściu warstwy sieciowej nadal wykonywane jest uwierzytelnianie SQL Server lub uwierzytelnianie Windows, a następnie sprawdzane są uprawnienia konkretnego loginu.

Do podstawowego sprawdzenia dostępności portu w systemie Windows można użyć polecenia Test-NetConnection -ComputerName nazwa-serwera -Port 1433. Wynik z TcpTestSucceeded : True potwierdza możliwość nawiązania połączenia TCP z tego konkretnego komputera, ale nie potwierdza poprawności konfiguracji loginu, istnienia wskazanej bazy ani działania aplikacji. Wynik negatywny może oznaczać blokadę zapory, brak nasłuchu, błędny adres, filtrację po drodze albo użycie innego portu przez instancję.

Weryfikacja konfiguracji domyślnej instancji

Numer portu należy sprawdzić w SQL Server Configuration Manager, w ustawieniach protokołu TCP/IP dla właściwej instancji. W sekcji adresów IP można znaleźć pola TCP Dynamic Ports oraz TCP Port. Dla stałego portu 1433 pole TCP Port powinno zawierać wartość 1433, natomiast konfiguracja dynamiczna nie powinna powodować równoczesnego wybierania przypadkowego portu dla tego samego adresu. Po zmianie ustawień protokołu TCP/IP usługa SQL Server wymaga ponownego uruchomienia, aby rozpoczęła nasłuch według nowej konfiguracji.

Rzeczywisty nasłuch można potwierdzić lokalnie poleceniem netstat -ano i wyszukać wpis zawierający :1433 oraz stan LISTENING. Numer procesu z kolumny PID można następnie porównać z procesem usługi SQL Server. Taki test rozróżnia sytuację, w której zapora blokuje istniejący nasłuch, od sytuacji, w której żadna usługa nie otworzyła portu 1433. W środowisku z wieloma adresami IP warto również sprawdzić, czy SQL Server nasłuchuje na właściwym adresie, a nie tylko na interfejsie lokalnym.

Domyślna instancja SQL Server może korzystać ze stałego portu 1433, lecz administrator może zmienić tę wartość. Nazwane instancje często używają portów dynamicznych, dlatego sama nazwa instancji, na przykład zapis serwer\instancja, nie oznacza automatycznie użycia portu 1433. Do odszukania portu nazwanej instancji klient może korzystać z usługi SQL Server Browser, która używa UDP 1434, ale jest to odrębny mechanizm i nie zastępuje reguły TCP dla portu, na którym faktycznie nasłuchuje SQL Server.

Objawy blokady i bezpieczna diagnostyka połączenia

Brak dostępu do TCP 1433 może powodować błędy informujące o niemożności otwarcia połączenia z serwerem lub instancją. W praktyce podobny objaw może wystąpić także przy wyłączonym TCP/IP, zatrzymanej usłudze SQL Server, nieprawidłowej nazwie hosta, błędnym porcie albo regule zapory zastosowanej do niewłaściwego profilu sieciowego. Dlatego diagnostykę należy prowadzić warstwowo: najpierw ustalić adres rozwiązywany przez nazwę, następnie sprawdzić osiągalność hosta, test TCP na właściwym porcie, lokalny nasłuch oraz dopiero później uwierzytelnianie i uprawnienia.

W konfiguracji zapory warto rozróżnić regułę dla portu od reguły dla programu. Reguła portowa dla TCP 1433 powinna dotyczyć ruchu przychodzącego do komputera serwera, a nie wyłącznie ruchu wychodzącego z komputera klienta. Jeżeli połączenia są możliwe lokalnie, lecz nie działają z innej maszyny, przyczyną może być zapora systemu Windows, zapora urządzenia sieciowego lub filtr na trasie. Jeżeli połączenie TCP jest udane, ale klient otrzymuje błąd logowania, dalszego problemu należy szukać w trybie uwierzytelniania, danych logowania, mapowaniu użytkownika do bazy lub stanie samej bazy, a nie w otwarciu portu.

Podczas diagnostyki i naprawy infrastruktury SQL Server należy zapisać dokładną nazwę instancji, adres serwera, skonfigurowany port oraz źródło próby połączenia. Taka dokumentacja pozwala uniknąć otwierania niewłaściwych portów i ułatwia porównanie konfiguracji klienta z ustawieniami usługi. W przypadku zmiany portu z 1433 na inną wartość reguła zapory, parametry połączenia i ewentualne aliasy klientów muszą wskazywać tę samą wartość; częściowa zmiana konfiguracji pozostawia połączenie niespójne i może generować objawy wyglądające jak awaria SQL Server.