Włączenie TCP/IP

Włączenie TCP/IP jest niezbędne do nawiązywania połączeń sieciowych z instancją SQL Server.

Włączenie TCP/IP — czym jest ta funkcja

Włączenie TCP/IP oznacza aktywowanie jednego z podstawowych protokołów komunikacyjnych, za pomocą którego urządzenia i programy wymieniają dane w sieci. W kontekście Microsoft SQL Server ustawienie to pozwala na przyjmowanie połączeń z aplikacji działających na tym samym komputerze albo na innych urządzeniach podłączonych do tej samej sieci. Bez aktywnego TCP/IP klient może nie odnaleźć właściwej instancji, nawet jeśli usługa SQL Server działa i baza danych została poprawnie utworzona.

TCP/IP nie jest bazą danych ani osobną usługą przechowującą informacje. Jest sposobem przekazywania pakietów pomiędzy punktem, z którego pochodzi żądanie, a punktem, który ma na nie odpowiedzieć. W praktyce aplikacja wysyła żądanie do określonego adresu oraz portu, a SQL Server oczekuje na takim połączeniu i przekazuje dalej zapytania do odpowiedniej instancji. Włączenie protokołu w konfiguracji SQL Server nie oznacza jeszcze, że każde połączenie będzie możliwe. Znaczenie mają także adres urządzenia, numer portu, reguły zapory, stan usługi oraz sposób określania nazwy instancji.

Problem często pojawia się po instalacji programu, zmianie ustawień sieciowych albo przy próbie połączenia z aplikacji znajdującej się na innym komputerze. Połączenie lokalne może działać przez mechanizm dostępny wyłącznie na jednej maszynie, natomiast dostęp zdalny wymaga właściwie przygotowanego TCP/IP. Z tego powodu sama obecność bazy w narzędziu administracyjnym nie potwierdza jeszcze gotowości do komunikacji zewnętrznej.

Włączenie TCP/IP a inne sposoby komunikacji

W środowisku SQL Server może być dostępnych kilka mechanizmów komunikacyjnych. Named Pipes, czyli potoki nazwane, są często kojarzone z połączeniami w obrębie określonej sieci systemowej. Shared Memory służy przede wszystkim do komunikacji lokalnej, gdy aplikacja i SQL Server pracują na tym samym komputerze. TCP/IP ma szersze zastosowanie, ponieważ działa zarówno lokalnie, jak i pomiędzy odrębnymi urządzeniami, o ile sieć i zabezpieczenia dopuszczają taki ruch.

Porównanie tych mechanizmów pomaga ustalić, gdzie znajduje się przyczyna problemu. Jeżeli aplikacja łączy się lokalnie, ale odrzuca połączenie z innego urządzenia, należy sprawdzić TCP/IP, port nasłuchu oraz zaporę. Jeżeli nie działa nawet komunikacja na tym samym komputerze, przyczyną może być zatrzymana usługa, błędna nazwa instancji, uszkodzona konfiguracja klienta albo brak właściwego sterownika. Włączenie TCP/IP jest więc ważnym etapem, lecz nie zastępuje pełnej weryfikacji połączenia.

Warto odróżnić protokół od adresu i portu. Adres wskazuje urządzenie lub interfejs sieciowy, natomiast port wskazuje logiczny punkt, na którym dana usługa oczekuje na połączenia. Dwa programy mogą działać na tym samym komputerze i korzystać z TCP/IP, ale nasłuchiwać na innych portach. Jeżeli w konfiguracji klienta podano niewłaściwy port, aktywny protokół nie wystarczy do uzyskania dostępu. Równie istotne jest sprawdzenie, czy wybrana instancja korzysta ze stałego portu, czy z ustawienia przydzielanego dynamicznie.

W przypadku instancji nazwanej może być potrzebna dodatkowa informacja pozwalająca odnaleźć właściwy port. Z tego względu stosuje się albo poprawnie skonfigurowaną usługę pomocniczą, albo bezpośredni zapis nazwy hosta i portu. To drugie rozwiązanie bywa łatwiejsze do sprawdzenia, ponieważ ogranicza liczbę elementów pośredniczących. Każda zmiana powinna jednak zostać udokumentowana, aby późniejsza konserwacja nie opierała się na przypadkowych ustawieniach.

Włączenie TCP/IP — typowe problemy konfiguracyjne

Najczęstszym problemem jest aktywowanie TCP/IP w niewłaściwej instancji. Na jednym komputerze może znajdować się więcej niż jedna instalacja SQL Server, a każda z nich ma własne ustawienia protokołów. Zmiana konfiguracji w jednej instancji nie poprawi połączenia z inną. Przed rozpoczęciem prac należy zatem ustalić nazwę instancji używanej przez aplikację oraz sprawdzić, czy edytowane ustawienia dotyczą właściwego składnika.

Drugą częstą przyczyną jest brak ponownego uruchomienia usługi po zmianie konfiguracji. Narzędzie administracyjne może zapisać nowe ustawienie, lecz działający proces nadal korzysta z poprzedniego stanu. Dopiero restart odpowiedniej usługi powoduje ponowne wczytanie konfiguracji i rozpoczęcie nasłuchiwania zgodnie z nowymi parametrami. Restart powinien być wykonany w sposób zaplanowany, ponieważ na czas operacji aplikacje korzystające z bazy mogą utracić połączenie.

Problemy może powodować także zapora systemowa. Włączenie TCP/IP nie otwiera automatycznie ruchu przychodzącego i nie usuwa reguł bezpieczeństwa. Jeżeli zapora blokuje port używany przez SQL Server, próba połączenia może kończyć się przekroczeniem czasu oczekiwania albo komunikatem o braku dostępności hosta. Należy zweryfikować reguły dla właściwego profilu sieci oraz ograniczyć zakres dopuszczonego ruchu do potrzebnego minimum.

Do błędów prowadzą również niejednoznaczne nazwy urządzeń, nieaktualny adres, wyłączony interfejs sieciowy i ustawienia klienta wskazujące na inną maszynę. Warto sprawdzić po kolei: rozpoznawanie nazwy, osiągalność urządzenia, dostępność portu oraz możliwość uwierzytelnienia. Taki porządek pozwala oddzielić problem sieciowy od problemu z kontem, uprawnieniami lub samą bazą.

Osobną kategorię stanowią ustawienia protokołu IP na komputerze. Nieprawidłowa maska, brama, adres DNS albo konflikt adresów może sprawić, że usługa działa poprawnie, lecz pakiety nie docierają do celu. Jeżeli trudność dotyczy tylko jednego urządzenia, należy porównać jego konfigurację z innym sprawnym stanowiskiem i sprawdzić, czy połączenie nie jest ograniczane przez lokalne oprogramowanie ochronne.

Włączenie TCP/IP — praktyczne wskazówki diagnostyczne

Prace najlepiej rozpocząć od zebrania informacji o aplikacji, instancji oraz miejscu, z którego ma być wykonywane połączenie. Należy ustalić, czy chodzi o dostęp lokalny, czy o komunikację pomiędzy różnymi komputerami, a następnie zapisać dokładny komunikat błędu. Różnica pomiędzy odmową połączenia, brakiem odnalezienia instancji i przekroczeniem czasu oczekiwania może wskazywać na zupełnie inną przyczynę.

W narzędziu SQL Server Configuration Manager trzeba odszukać ustawienia protokołów dla właściwej instancji i sprawdzić status TCP/IP. Po aktywowaniu protokołu należy przejrzeć jego właściwości, zwłaszcza sekcję dotyczącą adresów IP i portów. Nie powinno się zmieniać wielu parametrów jednocześnie, ponieważ utrudnia to ustalenie, która modyfikacja przyniosła efekt. Bezpieczniej jest wykonać jedną zmianę, zrestartować odpowiednią usługę i przeprowadzić test.

Test powinien obejmować zarówno nazwę urządzenia, jak i bezpośredni adres. Jeżeli połączenie działa po adresie, lecz nie działa po nazwie, problem może dotyczyć rozpoznawania nazw. Jeżeli nie działa żadna z metod, należy sprawdzić port, zaporę i stan usługi. W dokumentacji warto odnotować użyty adres, port, nazwę instancji oraz wynik testu, ponieważ te informacje ułatwiają późniejszą obsługę.

Nie należy wyłączać zapory na stałe tylko po to, aby szybko potwierdzić hipotezę. Takie działanie może chwilowo zmienić wynik testu, ale nie rozwiązuje problemu i osłabia ochronę urządzenia. Lepszym rozwiązaniem jest utworzenie precyzyjnej reguły dla właściwego portu i zakresu adresów, a następnie sprawdzenie połączenia z uprawnionego stanowiska. Po zakończeniu prac należy usunąć tymczasowe wyjątki oraz zachować opis docelowej konfiguracji.

Przydatne jest także rozdzielenie testu warstwy sieciowej od testu aplikacji. Najpierw można potwierdzić, że urządzenie odpowiada i że port jest dostępny, a dopiero potem sprawdzać logowanie do SQL Server. Jeżeli port jest dostępny, ale logowanie nie działa, dalszej uwagi wymagają dane uwierzytelniające, tryb autoryzacji, uprawnienia użytkownika oraz stan bazy.

Włączenie TCP/IP — kiedy zgłosić się do serwisu

Pomoc serwisowa jest wskazana, gdy po aktywowaniu protokołu i ponownym uruchomieniu usługi nadal występuje błąd, nie jest znana właściwa instancja albo zmiana ustawień mogłaby zakłócić pracę ważnej aplikacji. Dotyczy to także sytuacji, w której problem pojawił się po wymianie urządzenia sieciowego, zmianie systemu, instalacji programu ochronnego lub przeniesieniu bazy na inny komputer. Przed przekazaniem sprzętu warto przygotować komunikat błędu, nazwę aplikacji i informację, czy połączenie ma być lokalne, czy zdalne.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się diagnostyką oraz naprawą laptopów i komputerów PC, dlatego można zgłosić problem związany z konfiguracją systemu, usługami sieciowymi lub komunikacją aplikacji z bazą. Przy zgłoszeniu dobrze opisać, co zostało już sprawdzone, czy problem dotyczy jednego stanowiska oraz czy inne programy korzystające z sieci działają prawidłowo.

Nie powinno się samodzielnie usuwać plików konfiguracyjnych, zmieniać wielu usług naraz ani instalować przypadkowych narzędzi naprawczych. Takie działania mogą utrudnić odtworzenie przyczyny i zmienić stan środowiska. Prawidłowo wykonane włączenie TCP/IP obejmuje nie tylko zaznaczenie odpowiedniej opcji, lecz także dopasowanie portu, sprawdzenie usługi, zapory i parametrów klienta oraz wykonanie kontrolnego połączenia. Dzięki temu można ustalić, czy problem wynika z konfiguracji SQL Server, sieci, zabezpieczeń, czy z ustawień samej aplikacji.