Reguły portów TCP/IP

Reguły portów TCP/IP w zaporze decydują, które adresy mogą nawiązać połączenie z instancją SQL Server.

Rola reguł portów TCP/IP w SQL Server

Reguły portów TCP/IP w zaporze sieciowej określają, jaki ruch może dotrzeć do usługi SQL Server działającej na konkretnym komputerze. Sama reguła zapory nie nadaje usłudze adresu ani portu. Musi odpowiadać konfiguracji protokołu TCP/IP ustawionej dla danej instancji SQL Server. Jeżeli zapora blokuje port nasłuchu, klient może otrzymywać komunikaty o przekroczeniu limitu czasu, odrzuceniu połączenia albo braku możliwości odnalezienia serwera, mimo że proces SQL Server działa poprawnie.

W regule przychodzącej można określić między innymi protokół, lokalny port, dozwolone adresy źródłowe, profile sieciowe oraz zakres interfejsów, na których reguła obowiązuje. Dla połączenia z bazą danych najczęściej potrzebna jest reguła dla TCP, ponieważ właściwa komunikacja klienta z silnikiem SQL Server odbywa się przez TCP. Otwieranie całego zakresu portów lub wszystkich adresów źródłowych zwiększa powierzchnię dostępu i nie jest równoważne z precyzyjną regułą dla portu używanego przez konkretną instancję.

Port instancji domyślnej i instancji nazwanej

Instancja domyślna SQL Server standardowo korzysta z portu TCP 1433, o ile administrator nie zmienił tej konfiguracji. W takim przypadku klient może łączyć się z użyciem nazwy hosta i portu, na przykład w formie serwer,1433. Reguła zapory powinna zezwalać na ruch przychodzący TCP na rzeczywistym porcie skonfigurowanym dla instancji, a nie tylko na porcie uznawanym za domyślny. Numer portu można sprawdzić w SQL Server Configuration Manager w ustawieniach protokołu TCP/IP danej instancji.

Instancje nazwane często używają portów dynamicznych. Ich numer może zostać zapisany w polu TCP Dynamic Ports dla sekcji IPAll, natomiast stały port można wskazać w polu TCP Port. Przy konfiguracji stałego portu należy usunąć nieaktualny wpis portu dynamicznego, aby uniknąć niejednoznaczności, a następnie zrestartować usługę SQL Server. Jeżeli instancja nadal korzysta z portu dynamicznego, reguła zapory musi obejmować aktualnie przydzielony numer, który może zmienić się po ponownym uruchomieniu usługi.

SQL Server Browser i rozpoznawanie instancji

Usługa SQL Server Browser służy do wskazywania klientom numeru portu przypisanego do instancji, zwłaszcza gdy używana jest instancja nazwana albo port dynamiczny. Browser nasłuchuje na porcie UDP 1434. Reguła dla UDP 1434 nie zastępuje reguły dla portu TCP instancji: pierwsza umożliwia zapytanie o informacje o instancji, a druga pozwala na właściwą sesję z silnikiem bazy danych. Otwarcie UDP 1434 bez udostępnienia portu TCP instancji nie zapewni kompletnego połączenia.

Alternatywą dla mechanizmu wykrywania przez Browser jest podanie portu bezpośrednio w nazwie serwera, na przykład serwer,51433, jeśli instancja została skonfigurowana na TCP 51433. Takie połączenie ogranicza zależność od zapytań do SQL Server Browser, ale wymaga znajomości aktualnego portu i poprawnego wpisu DNS lub adresu IP. W środowisku z zaporą należy również upewnić się, że klient może dotrzeć do właściwego adresu interfejsu serwera, ponieważ reguła ograniczona do innego profilu sieciowego albo interfejsu nie zadziała dla danego połączenia.

Sprawdzanie reguły i diagnostyka połączenia

Po zmianie konfiguracji należy potwierdzić, że SQL Server rzeczywiście nasłuchuje na oczekiwanym adresie i porcie. W systemie Windows można użyć polecenia Test-NetConnection serwer -Port 1433, zastępując nazwę hosta i numer portu wartościami właściwymi dla danej instancji. Wynik z TcpTestSucceeded : True potwierdza możliwość zestawienia połączenia TCP z tego komputera, ale nie dowodzi jeszcze poprawnego uwierzytelnienia ani uprawnień do bazy. Wynik negatywny wskazuje na problem z trasą, nasłuchem usługi, numerem portu albo regułą zapory.

Jeżeli test TCP kończy się powodzeniem, a aplikacja nadal nie łączy się z SQL Server, trzeba sprawdzić nazwę instancji, sposób uwierzytelniania, uprawnienia konta oraz konfigurację klienta. Jeżeli test kończy się niepowodzeniem, warto porównać numer portu w SQL Server Configuration Manager z portem użytym w regule zapory i w parametrach połączenia. Należy też sprawdzić, czy usługa SQL Server została zrestartowana po zmianie portu, czy reguła jest włączona oraz czy działa dla aktywnego profilu sieciowego. Diagnostyka powinna obejmować również lokalne i zewnętrzne zapory, ponieważ blokada może występować na obu końcach połączenia.