Statyczne porty TCP

Statyczne porty TCP upraszczają konfigurację sieciową, eliminując konieczność korzystania z SQL Server Browser.

Rola statycznego portu TCP w SQL Server

Statyczny port TCP w SQL Server to numer portu przypisany konkretnej instancji silnika bazy danych i utrzymywany po ponownym uruchomieniu usługi. Klient, który zna adres hosta oraz ten numer, może nawiązać połączenie bez odpytywania usługi SQL Server Browser o aktualny port instancji. Rozwiązanie dotyczy warstwy komunikacji sieciowej, a nie sposobu przechowywania tabel, wykonywania zapytań czy uwierzytelniania użytkowników. Samo ustawienie portu nie nadaje uprawnień do bazy i nie omija kontroli dostępu.

W przypadku domyślnej instancji SQL Server często stosowanym portem jest TCP 1433, ale nie jest to bezwarunkowa reguła dla każdej instalacji. Administrator może przypisać instancję do innego numeru, a używany port trzeba potwierdzić w konfiguracji danego środowiska. Nazwane instancje mogą korzystać z portów dynamicznych, wybieranych podczas uruchamiania usługi. Zastąpienie portu dynamicznego statycznym oznacza, że numer nie powinien zmieniać się po restarcie, co ułatwia przygotowanie reguł zapory i konfiguracji klientów.

SQL Server Configuration Manager i przypisanie numeru

Port TCP ustawia się dla protokołu TCP/IP przypisanego do konkretnej instancji, a nie dla całego systemu Windows. W SQL Server Configuration Manager należy przejść do konfiguracji sieci SQL Server, wybrać protokół TCP/IP właściwy dla danej instancji i otworzyć jego właściwości. W sekcji adresów IP można znaleźć osobne ustawienia dla adresów lokalnych oraz pozycję IPAll. Pole TCP Dynamic Ports służy do portów dynamicznych, natomiast TCP Port określa port statyczny. Aby wymusić stały numer, konfiguracja nie może jednocześnie pozostawiać aktywnej wartości w polu portu dynamicznego dla tego samego zakresu ustawień.

Zmiana konfiguracji protokołu TCP/IP zwykle wymaga ponownego uruchomienia usługi SQL Server, ponieważ silnik odczytuje ustawienia podczas startu. Po restarcie należy sprawdzić log uruchomieniowy SQL Server albo bieżące nasłuchiwanie systemu, aby potwierdzić, że instancja rzeczywiście otworzyła oczekiwany port. Weryfikacja jest ważna, ponieważ zmiana wpisu konfiguracyjnego bez restartu może pozostawić działającą usługę na poprzednim porcie. Trzeba także upewnić się, że TCP/IP jest włączony, ponieważ sam numer portu nie zadziała, gdy protokół sieciowy instancji pozostaje wyłączony.

Połączenie bez pośrednictwa SQL Server Browser

SQL Server Browser nasłuchuje standardowo na UDP 1434 i pomaga klientom ustalić port używany przez nazwaną instancję. Przy połączeniu bezpośrednim klient otrzymuje jednak numer portu z konfiguracji aplikacji lub użytkownika. Typowy zapis adresu ma postać nazwa_hosta,port, na przykład db01,51433; przecinek oddzielający nazwę hosta od numeru portu jest częścią składni używanej przez klientów SQL Server. W takim wariancie klient nie musi pytać SQL Server Browser o lokalizację instancji.

Ustawienie statycznego portu nie wyłącza automatycznie SQL Server Browser i nie sprawia, że każda forma adresu instancji przestaje go potrzebować. Jeżeli klient podaje wyłącznie nazwę hosta oraz nazwę nazwanej instancji, może nadal próbować odszukać port za pośrednictwem Browser. Bez tej usługi należy wskazać port jawnie albo zastosować konfigurację klienta, która zna mapowanie instancji na port. W praktyce ogranicza to zależność od UDP 1434, ale wymaga konsekwentnego przekazania właściwego numeru wszystkim aplikacjom, sterownikom i narzędziom administracyjnym korzystającym z SQL Server.

Reguła zapory sieciowej musi zezwalać na ruch przychodzący TCP do portu, na którym nasłuchuje dana instancja. Otworzenie UDP 1434 nie zastępuje otwarcia właściwego portu TCP, ponieważ są to różne funkcje: Browser przekazuje informację o instancji, a silnik SQL Server obsługuje właściwe połączenie danych. Z drugiej strony samo otwarcie portu w zaporze nie potwierdza dostępności usługi. W diagnostyce trzeba rozdzielić rozwiązywanie nazwy hosta, osiągalność adresu, reguły zapory, nasłuchiwanie procesu oraz późniejszą autoryzację w SQL Server.

Kontrola konfiguracji i diagnostyka po zmianie

Diagnostykę należy rozpocząć od ustalenia, z którą instancją klient próbuje się łączyć i jaki port ma być używany. Następnie warto porównać konfigurację w SQL Server Configuration Manager z wpisem w logu uruchomieniowym oraz sprawdzić, czy port jest zajęty przez właściwy proces. Jeżeli połączenie z adresem host,port nie działa, błąd może wynikać z nieuruchomionej usługi, wyłączonego TCP/IP, nasłuchiwania tylko na innym adresie IP, blokady zapory albo błędnego numeru portu. Dopiero po potwierdzeniu warstwy transportowej należy analizować nazwę bazy, sposób uwierzytelniania i uprawnienia.

Zmiana portu wymaga aktualizacji wszystkich miejsc, w których zapisano dawny adres instancji. Dotyczy to między innymi parametrów połączeń aplikacji, aliasów klienta SQL Server oraz reguł zapory na hoście. W przypadku kilku instancji każdy silnik powinien mieć jednoznacznie ustalony port, aby uniknąć kolizji i pomyłek diagnostycznych. Jeżeli używana jest nazwana instancja, należy również sprawdzić, czy aplikacja rzeczywiście przekazuje numer portu, a nie tylko nazwę instancji. Pomyślne połączenie lokalne nie dowodzi jeszcze poprawnej dostępności z innego komputera, ponieważ ruch lokalny i ruch przez sieć mogą podlegać innym regułom.

Przy problemach z połączeniem do SQL Server można przeprowadzić test osiągalności wskazanego portu z komputera klienckiego, a następnie sprawdzić logi usługi i konfigurację zapory. Wynik testu trzeba interpretować ostrożnie: otwarty port oznacza możliwość nawiązania połączenia TCP, ale nie potwierdza poprawnych danych logowania ani dostępu do konkretnej bazy. W razie ingerencji w konfigurację warto zapisać pierwotny numer portu i zakres zmiany, aby można było odtworzyć poprzedni stan oraz porównać zachowanie aplikacji przed i po modyfikacji.