Windows Firewall a SQL Server

Windows Firewall wymaga jawnej reguły dla portów SQL Server, inaczej połączenia z sieci zostaną zablokowane.

Jak zapora systemu Windows traktuje ruch do SQL Server

SQL Server przyjmuje połączenia sieciowe przez protokół TCP, dlatego zapora systemu Windows musi zezwolić na ruch przychodzący do portu, na którym nasłuchuje konkretna instancja. Sama instalacja silnika bazy danych nie powoduje automatycznego otwarcia wszystkich potrzebnych portów. Jeżeli reguła zapory nie obejmuje właściwego portu, klient może otrzymać błąd połączenia, przekroczenie limitu czasu albo komunikat wskazujący, że serwer jest niedostępny.

W przypadku domyślnej instancji SQL Server często używany jest port TCP 1433, ale nie należy zakładać tego bez sprawdzenia konfiguracji. Administrator może przypisać instancji inny port, a usługa może być skonfigurowana bez nasłuchiwania TCP. Reguła zapory musi odpowiadać rzeczywistemu ustawieniu w SQL Server Configuration Manager, w szczególności w konfiguracji protokołu TCP/IP dla danej instancji.

Port TCP 1433, instancje nazwane i SQL Server Browser

Domyślna instancja SQL Server może nasłuchiwać na stałym porcie TCP 1433. W takim układzie reguła przychodząca dla TCP 1433 wystarcza od strony zapory do przekazania ruchu do usługi, o ile klient łączy się z właściwym adresem serwera, a usługa SQL Server działa. Numer 1433 jest typowym ustawieniem domyślnej instancji, lecz pozostaje konfiguracją, którą trzeba potwierdzić, a nie uniwersalną właściwością każdej instalacji.

Instancje nazwane SQL Server mogą korzystać z dynamicznie przydzielanych portów TCP. Klient, który otrzymuje nazwę instancji zamiast numeru portu, może korzystać z usługi SQL Server Browser. Browser używa portu UDP 1434 do udzielania informacji o portach instancji. Wtedy zapora musi uwzględniać zarówno ruch TCP do portu używanego przez samą instancję, jak i UDP 1434, jeżeli wykrywanie instancji przez Browser jest rzeczywiście potrzebne. Alternatywą jest ustawienie stałego portu dla instancji nazwanej i wskazywanie tego portu bezpośrednio w konfiguracji klienta.

Tworzenie i weryfikacja reguły zapory dla konkretnej instancji

Regułę można utworzyć w zaporze systemu Windows z zabezpieczeniami zaawansowanymi, wybierając regułę dla portu przychodzącego TCP i wpisując potwierdzony numer portu SQL Server. Przy regule dla domyślnej instancji będzie to często TCP 1433, natomiast dla instancji nazwanej należy użyć portu odczytanego z ustawień TCP/IP lub z logu SQL Server. Reguła powinna być przypisana tylko do profili sieciowych, w których serwer ma przyjmować połączenia, oraz ograniczona do wymaganych adresów źródłowych, jeżeli topologia sieci na to pozwala.

Przydatne jest sprawdzenie stanu reguł i nasłuchu na samym serwerze. W PowerShell można użyć polecenia Get-NetTCPConnection -LocalPort 1433 -State Listen, zastępując numer portu faktycznym portem instancji. Do sprawdzenia dostępności z komputera klienckiego służy między innymi Test-NetConnection -ComputerName nazwa-serwera -Port 1433. Wynik testu potwierdza możliwość zestawienia połączenia TCP, ale nie potwierdza poprawnego uwierzytelnienia ani działania konkretnej bazy danych.

Jeżeli port jest osiągalny, a logowanie nadal się nie udaje, przyczyna może znajdować się poza zaporą: usługa SQL Server może być zatrzymana, protokół TCP/IP wyłączony, nazwa serwera może wskazywać błędny adres, a konfiguracja instancji może wymagać innego portu. Przy połączeniu do instancji nazwanej trzeba również rozróżnić problem z samym portem instancji od problemu z SQL Server Browser. Najbardziej jednoznaczny test polega na połączeniu z nazwą serwera i jawnym numerem portu, na przykład tcp:nazwa-serwera,51433, jeśli taki port został skonfigurowany.

Bezpieczna diagnostyka połączenia z SQL Server przez sieć

Diagnozę należy prowadzić od warstwy sieciowej do warstwy usługi. Najpierw trzeba potwierdzić, że nazwa serwera rozwiązuje się na oczekiwany adres IP, następnie sprawdzić osiągalność portu TCP i dopiero później analizować błąd klienta SQL Server. Warto porównać wynik testu wykonany lokalnie na serwerze z wynikiem z komputera klienckiego. Jeżeli lokalny test działa, a zdalny nie, podejrzane są reguły zapory, filtracja sieciowa lub routing.

Reguła otwierająca port powinna być możliwie precyzyjna: właściwy protokół, właściwy port, właściwy profil zapory i ograniczony zakres adresów źródłowych. Otwieranie całego zakresu portów albo zezwalanie na dowolny ruch przychodzący utrudnia późniejszą diagnostykę i zwiększa ekspozycję usługi. Po zmianie konfiguracji trzeba sprawdzić, czy reguła jest aktywna, czy nie koliduje z regułą blokującą oraz czy zapora działa na interfejsie, przez który faktycznie dociera ruch.

W środowisku z wieloma instancjami każdą instancję należy analizować osobno, ponieważ mogą używać różnych portów i różnych ustawień protokołów. Pomocne są logi SQL Server, konfiguracja SQL Server Configuration Manager oraz dzienniki zapory systemu Windows. Dopiero zgodność tych trzech źródeł pozwala stwierdzić, czy połączenie jest kierowane do właściwej usługi, czy problem dotyczy wyłącznie blokady portu, czy też występuje błąd konfiguracji samego SQL Server.