Połączenie z Azure SQL

Połączenie z Azure SQL to dostęp do bazy w chmurze Microsoftu z poziomu aplikacji lub narzędzia analitycznego.

Na czym polega połączenie z Azure SQL Database

Połączenie z Azure SQL oznacza zestaw czynności, dzięki którym aplikacja, klient administracyjny albo narzędzie analityczne uzyskuje dostęp do relacyjnej bazy danych uruchomionej w chmurze Microsoft Azure. W praktyce najczęściej chodzi o usługę Azure SQL Database, czyli zarządzany silnik zgodny z Microsoft SQL Server, udostępniany przez punkt końcowy serwera logicznego. Aplikacja nie łączy się z adresem całej platformy Azure, lecz z konkretną nazwą serwera i nazwą bazy danych.

Do nawiązania sesji potrzebne są między innymi adres serwera, port TCP, nazwa bazy, metoda uwierzytelniania oraz ustawienia szyfrowania. Typowy punkt końcowy Azure SQL Database ma postać nazwy zakończonej domeną .database.windows.net, a standardowa komunikacja odbywa się przez port TCP 1433. Samo podanie poprawnego loginu i hasła nie wystarcza, jeżeli zapora usługi nie zezwala na ruch z adresu klienta albo aplikacja korzysta z nieprawidłowego trybu uwierzytelniania.

Adres serwera, port i reguły dostępu

Azure SQL Database filtruje połączenia na kilku poziomach. Pierwszym jest dostęp sieciowy do serwera logicznego. W jego ustawieniach mogą znajdować się reguły zapory dla publicznego adresu IPv4 lub zakresu adresów. Jeżeli klient działa poza dopuszczonym zakresem, próba połączenia kończy się komunikatem o odrzuceniu adresu przez reguły serwera. Zmiana adresu publicznego routera, korzystanie z sieci komórkowej albo połączenie przez firmową bramę może więc spowodować błąd mimo niezmienionej konfiguracji aplikacji.

Znaczenie ma także zapora systemu operacyjnego, filtr sieciowy, serwer proxy i możliwość wykonania połączenia wychodzącego TCP na porcie 1433. Test rozwiązywania nazwy DNS potwierdza tylko, że nazwa serwera została odnaleziona; nie dowodzi, że port jest osiągalny ani że usługa zaakceptuje sesję. W środowisku z prywatnym punktem końcowym Azure SQL adres może być rozwiązywany przez prywatny DNS, a dostęp będzie możliwy wyłącznie z odpowiedniej sieci wirtualnej lub połączonej sieci lokalnej. Tego wariantu nie należy mieszać z publicznym dostępem regulowanym samymi regułami zapory.

Uwierzytelnianie i parametry klienta

Azure SQL Database obsługuje uwierzytelnianie SQL oraz uwierzytelnianie Microsoft Entra ID, wcześniej nazywane Azure Active Directory. W pierwszym wariancie klient przekazuje nazwę użytkownika i hasło zapisane w konfiguracji połączenia. W drugim używany jest token uzyskany przez użytkownika, aplikację lub inną wspieraną tożsamość. Token musi być przeznaczony dla usługi bazodanowej, a tożsamość musi mieć odpowiednie uprawnienia w bazie. Samo zalogowanie do portalu Azure nie oznacza automatycznie prawa do odczytu tabel.

W łańcuchu połączenia należy poprawnie wskazać nazwę bazy, serwer oraz wymaganie szyfrowania. Nowoczesne sterowniki powinny negocjować szyfrowane połączenie TLS i weryfikować certyfikat serwera. Błąd certyfikatu może wynikać ze starego sterownika, nieaktualnego magazynu certyfikatów, nieprawidłowej nazwy hosta lub ustawienia wyłączającego zaufanie do certyfikatu. Z kolei komunikat o braku bazy może oznaczać literówkę w parametrze Initial Catalog, a nie problem z siecią. Przy analizie trzeba rozdzielić błąd DNS, timeout TCP, odrzucenie przez zaporę, nieudaną autoryzację i brak uprawnień już po zalogowaniu.

W aplikacjach używających puli połączeń dodatkowym źródłem problemów jest przeterminowana sesja, limit liczby równoczesnych połączeń albo zbyt krótki czas oczekiwania. Prawidłowa konfiguracja powinna uwzględniać obsługę ponowień dla przejściowych błędów sieciowych, ale ponawianie nie naprawi błędnego hasła, nieistniejącej bazy ani blokady zapory. Warto również sprawdzić, czy sterownik obsługuje używaną metodę logowania i czy aplikacja nie odczytuje innego pliku konfiguracyjnego niż ten, który został zmieniony.

Diagnostyka błędów połączenia z Azure SQL

Diagnostykę należy rozpocząć od ustalenia, z jakiego urządzenia i adresu sieciowego wychodzi żądanie. Następnie sprawdza się rozpoznawanie nazwy serwera, możliwość zestawienia połączenia TCP oraz reguły zapory Azure SQL. Jeżeli port jest osiągalny, analizuje się parametry klienta, certyfikat TLS, wybraną metodę uwierzytelniania i uprawnienia do wskazanej bazy. Pomocne są dokładny kod błędu sterownika, czas wystąpienia problemu oraz informacja, czy awaria dotyczy wszystkich aplikacji, czy tylko jednego programu.

Na komputerze lokalnym można porównać działanie kilku klientów korzystających z tego samego sterownika lub biblioteki. Trzeba jednak zachować ostrożność przy kopiowaniu danych uwierzytelniających do logów, ponieważ pełny łańcuch połączenia może zawierać sekret. W przypadku niestabilnych połączeń porównuje się opóźnienia, timeouty i liczbę ponowień, a także sprawdza, czy problem pojawia się po zmianie sieci, aktualizacji sterownika lub zmianie reguł dostępu. Diagnostyka sprzętu może wykazać usterkę karty sieciowej, sterownika systemowego albo konfiguracji DNS, lecz nie zastępuje weryfikacji ustawień samej usługi Azure SQL.

Przy naprawie komputera ważne jest zachowanie rozdziału między problemem urządzenia a problemem konfiguracji chmurowej. Jeżeli inne usługi sieciowe działają poprawnie, a błąd dotyczy wyłącznie jednego serwera Azure SQL, bardziej prawdopodobna jest niezgodność parametrów, reguł dostępu lub uprawnień niż awaria laptopa. Neutralna ocena powinna wskazać sprawdzony etap: DNS, TCP, TLS, logowanie albo dostęp do bazy. Takie rozróżnienie ogranicza ryzyko wymiany sprawnych podzespołów i ułatwia przekazanie administratorowi precyzyjnych informacji technicznych.