Reguła dla SQL Server Browser

Reguła dla SQL Server Browser otwiera port UDP 1434 niezbędny do wykrywania instancji nazwanych.

Reguła dla SQL Server Browser — czym jest i do czego służy

Reguła dla SQL Server Browser jest ustawieniem zapory sieciowej, które pozwala na obsługę ruchu kierowanego do usługi SQL Server Browser. Jej podstawowym zadaniem jest dopuszczenie komunikacji przez port UDP 1434. Dzięki temu klient próbujący połączyć się z bazą danych może uzyskać informację o dostępnych instancjach nazwanych oraz o portach, na których te instancje przyjmują połączenia. Bez takiej wymiany aplikacja może nie odnaleźć właściwej instancji, nawet gdy sama usługa bazy danych działa prawidłowo.

SQL Server Browser nie jest właściwą bazą danych ani silnikiem wykonującym zapytania. Jest usługą pomocniczą, która odpowiada na zapytania dotyczące lokalizacji instancji. Przydatność tej usługi ujawnia się przede wszystkim wtedy, gdy na jednym komputerze działa więcej niż jedna instancja SQL Server albo gdy instancja nazwana korzysta z portu przydzielanego dynamicznie. Klient nie musi wówczas znać całej konfiguracji połączenia, ponieważ może otrzymać potrzebne dane od usługi Browser.

Samo utworzenie reguły nie uruchamia usługi, nie naprawia silnika SQL Server i nie gwarantuje poprawnego połączenia w każdej konfiguracji. Reguła jest jednym z elementów całego łańcucha komunikacji. Równie ważne pozostają: działająca usługa SQL Server Browser, poprawnie uruchomiona instancja, właściwe uprawnienia, dostępność interfejsu sieciowego oraz zgodność ustawień zapory po obu stronach połączenia.

SQL Server Browser i port UDP 1434 na tle innych połączeń

Warto rozdzielić dwa rodzaje ruchu, które bywają mylone podczas konfiguracji. Port UDP 1434 służy do zapytań kierowanych do SQL Server Browser. Odpowiedzi uzyskane za jego pośrednictwem mogą wskazać port TCP wykorzystywany później przez konkretną instancję SQL Server. Właściwa transmisja danych, logowanie, wykonywanie zapytań i obsługa sesji odbywają się już przez odpowiedni port TCP. Otwarcie UDP 1434 nie oznacza więc automatycznego otwarcia wszystkich portów potrzebnych do pracy z bazą.

Inaczej wygląda sytuacja w przypadku instancji domyślnej, która często korzysta ze znanego portu TCP. W takim układzie klient może łączyć się bez pośrednictwa SQL Server Browser, jeżeli port został wpisany bezpośrednio w konfiguracji. Instancja nazwana może natomiast wymagać odpowiedzi usługi Browser, szczególnie wtedy, gdy port nie został ustalony na stałe albo gdy użytkownik posługuje się nazwą w formacie SERWER\INSTANCJA zamiast wskazania konkretnego numeru portu.

Reguła dla portu UDP 1434 powinna być oceniana razem z regułą dla portu TCP przypisanego do właściwej instancji. Jeżeli zapora przepuszcza pierwsze zapytanie, ale blokuje późniejszy ruch TCP, nazwa serwera może zostać rozpoznana, lecz połączenie nadal nie zostanie ustanowione. Z kolei otwarcie portu TCP bez dostępu do Browser może nie wystarczyć, gdy aplikacja nie zna numeru portu i oczekuje automatycznego wykrycia instancji.

Na komputerach z więcej niż jednym profilem sieciowym znaczenie może mieć również zakres reguły. Inne ustawienia mogą obowiązywać dla sieci prywatnej, publicznej i domenowej. Zbyt szerokie dopuszczenie ruchu zwiększa powierzchnię dostępu, a zbyt wąskie może uniemożliwić komunikację aplikacjom działającym w zaufanej sieci. Zakres adresów źródłowych powinien odpowiadać rzeczywistym urządzeniom, które korzystają z bazy.

Instancje nazwane — typowe problemy z regułą dla SQL Server Browser

Najczęściej spotykanym problemem jest niedziałająca usługa SQL Server Browser. W takiej sytuacji reguła może być widoczna w zaporze, lecz nie pojawi się odpowiedź na zapytanie UDP 1434. Należy sprawdzić stan usługi, sposób jej uruchamiania oraz to, czy działa w kontekście właściwego systemu. Samo istnienie wpisu w regułach zapory nie świadczy o tym, że proces nasłuchuje i obsługuje żądania.

Drugą przyczyną bywa reguła utworzona dla niewłaściwego protokołu. UDP i TCP nie są zamienne. Reguła TCP dla portu 1434 nie zastąpi reguły UDP, ponieważ mechanizm wykrywania instancji korzysta z datagramów UDP. W podobny sposób reguła zezwalająca na ruch wychodzący nie musi rozwiązać problemu, gdy blokowany jest ruch przychodzący do komputera, na którym pracuje usługa Browser.

Problemy mogą wynikać także z lokalnej zapory, dodatkowego programu ochronnego, urządzenia filtrującego ruch albo konfiguracji routera. Jeżeli klient i serwer znajdują się w różnych podsieciach, odpowiedź UDP może zostać odrzucona po drodze. W środowisku z translacją adresów należy sprawdzić, czy nazwa hosta wskazuje właściwe urządzenie oraz czy zapytanie nie trafia do innego komputera o podobnej nazwie.

Warto zweryfikować, czy aplikacja rzeczywiście korzysta z nazwy instancji, czy może ma zapisany konkretny port. Pomocne jest porównanie kilku wariantów: połączenia z nazwą hosta, połączenia z nazwą hosta i instancją oraz połączenia z bezpośrednio podanym portem TCP. Wyniki takiego porównania wskazują, czy problem dotyczy wykrywania, właściwego ruchu do silnika, rozwiązywania nazwy, czy uwierzytelniania.

Nie należy też pomijać błędów wpisywanych w konfiguracji aplikacji. Spacja w nazwie instancji, pomylenie ukośnika odwrotnego z innym znakiem, literówka w nazwie hosta albo wskazanie nieaktualnego komputera mogą wyglądać jak problem z zaporą. Dopiero po sprawdzeniu nazwy, usługi i portów warto zmieniać zakres reguł.

Konfiguracja reguły dla portu UDP 1434 — praktyczne wskazówki

Podczas tworzenia reguły należy wskazać protokół UDP oraz lokalny port 1434. Nazwa reguły powinna jednoznacznie opisywać jej przeznaczenie, na przykład przez odwołanie do SQL Server Browser i numeru portu. Czytelne nazewnictwo ułatwia późniejszy audyt, rozróżnienie reguł oraz ustalenie, który wpis można bezpiecznie zmienić po modyfikacji konfiguracji.

Zakres działania powinien być możliwie precyzyjny. Jeżeli dostęp do bazy jest potrzebny tylko z określonych komputerów, należy ograniczyć adresy źródłowe do tych urządzeń lub do właściwego segmentu sieci. Wybór profilu sieciowego powinien wynikać z rzeczywistego sposobu pracy komputera. Przypadkowe włączenie reguły dla każdej sieci może pozostawić usługę dostępną także w miejscu, w którym nie jest to potrzebne.

Po zapisaniu ustawień należy wykonać test z urządzenia klienckiego, a nie tylko sprawdzić obecność wpisu w panelu zapory. Weryfikacja powinna obejmować rozpoznanie hosta, odnalezienie instancji, próbę zestawienia połączenia i rzeczywiste wykonanie prostego działania w aplikacji. Jeżeli dostępne są logi zapory, warto sprawdzić, czy pakiety UDP 1434 są odrzucane, akceptowane czy w ogóle nie docierają do komputera.

Bezpieczniejszym rozwiązaniem jest jawne ustalenie portu TCP dla instancji i wpisanie go w konfiguracji klientów, gdy nie jest potrzebne automatyczne wykrywanie. Wtedy rola Browser może zostać ograniczona, a reguły mogą być prostsze do kontrolowania. Takie podejście wymaga jednak konsekwencji: po zmianie portu trzeba zaktualizować konfigurację aplikacji, dokumentację oraz reguły zapory.

Przed zmianą ustawień warto zapisać aktualną konfigurację usług i reguł. Pozwala to odtworzyć stan początkowy, porównać efekty testów i uniknąć wielokrotnego otwierania kolejnych portów bez ustalenia przyczyny. Szczególną uwagę należy zwrócić na reguły odziedziczone po starszych instalacjach, ponieważ ich opis może nie odpowiadać obecnej konfiguracji.

Kiedy zgłosić regułę dla SQL Server Browser do serwisu

Zgłoszenie problemu do serwisu jest uzasadnione wtedy, gdy połączenie przestało działać po aktualizacji systemu, zmianie routera, przeniesieniu bazy na inny komputer albo instalacji dodatkowego programu ochronnego. Pomoc może być potrzebna również wtedy, gdy z jednego stanowiska dostęp działa, a z innego pojawia się błąd wykrywania instancji. Taki objaw często wskazuje na różnicę w profilach sieciowych, lokalnych regułach zapory lub sposobie rozwiązywania nazwy hosta.

W ramach przygotowania do zgłoszenia warto zanotować nazwę serwera, nazwę instancji, moment wystąpienia problemu oraz komunikat wyświetlany przez aplikację. Przydatna jest także informacja, czy połączenie działa przy bezpośrednim wskazaniu portu TCP, czy problem występuje tylko przy użyciu nazwy instancji. Nie należy jednak samodzielnie otwierać szerokiego dostępu do wielu portów, jeżeli nie ma pewności, które usługi są faktycznie wymagane.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się analizą takich przypadków, obejmującą sprawdzenie usługi, zapory, komunikacji między urządzeniami i konfiguracji aplikacji. Diagnostyka może doprowadzić do rozróżnienia problemu sieciowego od błędu samej instancji, niepoprawnych danych logowania albo uszkodzonej konfiguracji klienta. Po ustaleniu przyczyny możliwe jest uporządkowanie reguł i pozostawienie wyłącznie tych wyjątków, które są potrzebne do prawidłowej pracy.

Do serwisu warto zgłosić się także wtedy, gdy połączenie działa niestabilnie, pojawia się tylko po ponownym uruchomieniu komputera albo zależy od wybranej sieci. Powtarzalny test z kilku stanowisk pozwala ustalić, czy źródłem jest konkretny klient, komputer z bazą, urządzenie pośredniczące czy sama usługa SQL Server Browser. Takie uporządkowane podejście ogranicza przypadkowe zmiany i ułatwia zachowanie kontroli nad dostępem do danych.