Połączenia przez VPN

Połączenia przez VPN to zalecany sposób zdalnego dostępu do SQL Server zamiast wystawiania portu do internetu.

Rola tunelu VPN przy dostępie do SQL Server

Połączenie przez VPN tworzy szyfrowany tunel pomiędzy urządzeniem użytkownika a siecią, w której działa SQL Server. Ruch do serwera jest wtedy przesyłany przez logiczny interfejs sieciowy VPN, a instancja bazy nie musi być dostępna bezpośrednio z publicznego internetu. Z punktu widzenia klienta SQL Server może być osiągalny pod prywatnym adresem IP, nazwą hosta w sieci lokalnej albo adresem DNS rozwiązywanym dopiero po zestawieniu tunelu.

Takie rozwiązanie ogranicza powierzchnię ataku, ale samo zestawienie VPN nie zastępuje uwierzytelniania w SQL Server. Po uzyskaniu dostępu do sieci nadal trzeba poprawnie zalogować się do instancji przy użyciu uwierzytelniania systemu Windows albo uwierzytelniania SQL Server, zależnie od konfiguracji. Uprawnienia konta powinny być nadane w SQL Server zgodnie z rzeczywistym zakresem pracy, ponieważ dostęp do tunelu nie powinien automatycznie oznaczać pełnych praw do baz danych.

Adresowanie instancji i porty w tunelu

Dla domyślnej instancji SQL Server często używany jest port TCP 1433, jednak numer ten nie jest gwarantowany dla każdej instalacji. Nazwana instancja może korzystać z innego, skonfigurowanego portu TCP. Jeżeli klient łączy się z nazwą w formacie serwer\instancja, potrzebne może być odnalezienie portu instancji przez usługę SQL Server Browser, która standardowo wykorzystuje UDP 1434. W praktyce stabilniejsze i łatwiejsze do kontrolowania bywa wskazanie konkretnego hosta oraz portu, na przykład serwer,51433, jeśli taki port został przypisany do instancji.

Sam tunel VPN musi zapewniać trasę do adresu IP serwera, a zapora sieciowa powinna zezwalać na wymagany ruch między zakresem adresów VPN a adresem SQL Server. Jeżeli instancja nasłuchuje na TCP 1433, reguła zapory powinna dotyczyć tego portu i właściwych interfejsów. Przy nazwanej instancji trzeba sprawdzić rzeczywisty port TCP, ponieważ otwarcie wyłącznie portu 1433 może nie dać żadnego efektu. Weryfikacja powinna obejmować również rozwiązywanie nazwy DNS, tablicę routingu oraz możliwość nawiązania sesji TCP do wskazanego portu.

Uwierzytelnianie, szyfrowanie i kontrola dostępu

VPN chroni transmisję pomiędzy klientem a punktem zakończenia tunelu, lecz bezpieczeństwo połączenia z SQL Server zależy także od ustawień samego silnika. W konfiguracji SQL Server można wymagać szyfrowania połączeń, a certyfikat przypisany do instancji pozwala klientowi zweryfikować tożsamość serwera. W nowszych sterownikach klienta parametry takie jak Encrypt i TrustServerCertificate mają bezpośredni wpływ na sposób weryfikacji certyfikatu. Akceptowanie dowolnego certyfikatu bez sprawdzenia jego wiarygodności usuwa istotną część ochrony przed podstawieniem serwera.

Do uwierzytelniania systemu Windows przez VPN potrzebna jest odpowiednia łączność z usługami domenowymi, w tym poprawne rozwiązywanie nazw i dostęp do wymaganych kontrolerów domeny. Jeżeli te warunki nie są spełnione, logowanie domenowe może nie działać mimo poprawnego połączenia z portem SQL Server. Przy uwierzytelnianiu SQL Server klient korzysta z loginu zdefiniowanego w instancji, ale hasło nadal powinno być przesyłane wyłącznie w połączeniu zabezpieczonym zgodnie z konfiguracją sterownika i serwera. Diagnostyka powinna rozdzielać problem z tunelem, problem z siecią oraz odrzucenie poświadczeń przez SQL Server.

Diagnostyka przerwanych połączeń VPN z bazą

Przy problemach z dostępem do SQL Server warto najpierw ustalić, czy tunel VPN jest aktywny i jaki adres otrzymał klient. Następnie można sprawdzić, czy nazwa serwera rozwiązuje się do właściwego adresu prywatnego oraz czy istnieje trasa do tej sieci. Test portu powinien być wykonywany wobec konkretnego portu instancji, a nie tylko wobec nazwy hosta. Otwarty port potwierdza możliwość nawiązania sesji TCP, lecz nie potwierdza poprawnego uwierzytelnienia ani dostępu do konkretnej bazy.

Jeżeli połączenie działa po adresie IP, ale nie działa po nazwie instancji, przyczyną może być DNS, SQL Server Browser albo brak dostępu do UDP 1434. Jeżeli sesja zrywa się po okresie bezczynności, należy sprawdzić limity bezczynności po stronie koncentratora VPN, klienta VPN, zapory oraz urządzeń pośredniczących. W przypadku błędów szyfrowania trzeba porównać ustawienia sterownika z konfiguracją certyfikatu i wymuszaniem szyfrowania w SQL Server. Przy każdej zmianie warto zapisać użyty adres, port, nazwę instancji i dokładny komunikat błędu, ponieważ pozwala to oddzielić błąd routingu od problemu konfiguracji samego silnika.