SQL przez VPN: klient bezpośredni czy stacja robocza w sieci wewnętrznej?

Zespoły chcą SSMS na swoich laptopach, a szybkim rozwiązaniem jest opublikowanie portu SQL w puli VPN. Wolniejsza odpowiedź pyta, gdzie powinien działać proces klienta, ponieważ dostęp bezpośredni i wewnętrzna stacja robocza dają różne adresy źródłowe, zaufanie punktu końcowego i ścieżki danych. Żadna z nich nie jest automatycznie bezpieczna, a samo członkostwo w VPN niczego nie rozstrzyga. Porównaj projekty, zanim powstanie reguła zezwalająca.

Dwie ścieżki, dwa adresy źródłowe

Przy dostępie bezpośrednim laptop niesie konfigurację klienta i sam otwiera połączenie z bazą danych. Przy zdalnej stacji roboczej laptop otwiera sesję pulpitu, a stacja robocza nawiązuje połączenie SQL z własnego adresu. Baza danych widzi więc w pierwszym projekcie pulę VPN lub przetłumaczoną bramę, a w drugim adres stacji roboczej. Ta różnica decyduje, która reguła zapory i które uprawnienie SQL faktycznie obowiązują.

Laptop nadal kontroluje zdalną sesję, więc stacja robocza nie zastępuje uwierzytelniania użytkownika ani polityki sesji.

Sprawdź, co baza danych naprawdę widzi

Adres źródłowy się mierzy, a nie wywnioskowuje z diagramu. Odczytaj go po stronie serwera aktywnego połączenia.

Test-NetConnection sql.example.com -Port 1433
sqlcmd -S tcp:sql.example.com,1433 -N -d appdb -Q "select SUSER_SNAME() as login_name, DB_NAME() as db"

Test łączności dowodzi, że nasłuchujący akceptuje TCP z tej sieci, a zapytanie dowodzi, do którego logowania i której bazy danych dotarła sesja. Aby zobaczyć adres zapisany przez serwer, odpytaj sys.dm_exec_connections dla bieżącej sesji; zwraca on adres klienta po każdym tłumaczeniu. Jeśli ta wartość jest bramą, a nie laptopem, reguła hosta na użytkownika nie może działać na maszynie bazy danych. Zapisz zaobserwowaną wartość obok wybranego projektu, ponieważ ponowne połączenia i zmiany puli ją przesuwają.

Otwórz nasłuchujący i nic więcej

Otwórz tylko usługę, której potrzebuje wdrożenie. Znany 1433 to port instancji domyślnej, a nie uniwersalna stała.

Get-NetTCPConnection -State Listen -LocalPort 1433

Nazwane instancje często nasłuchują na porcie dynamicznym, a SQL Server Browser odpowiada na odnajdywanie przez UDP 1434, i ta zależność jest osobnym eksponowaniem, które trzeba uzasadnić. Przypięcie stałego portu do instancji usuwa potrzebę Browsera i stabilizuje reguły zapory. Zachowaj kontrole szyfrowania i certyfikatów, które klient już wykonuje, zamiast je wyłączać, aby test przeszedł. Następnie przyznaj role bazy danych dla obciążenia, zamiast dodawać całą grupę VPN do roli serwera.

Udowodnij ścieżkę dozwoloną i odrzuconą

Otwórz nową sesję jako zwykły zatwierdzony użytkownik i potwierdź tożsamość serwera, bazę danych oraz wymaganą operację. Następnie potwierdź wykluczenie: źródło lub konto spoza polityki musi nie przejść tego samego testu. W projekcie ze stacją roboczą sprawdź, że laptop nie może obejść granicy, docierając bezpośrednio do bazy danych. Przy dostępie bezpośrednim sprawdź, że trasa i reguła źródłowa nadal obowiązują po ponownym połączeniu.

Zapisz, gdzie działał klient, jakie źródło zaobserwowała baza danych i która reguła na to pozwoliła. To dowody, o które poprosi następny przegląd.