SQL через VPN: прямой клиент или внутренняя рабочая станция?

Команды хотят видеть SSMS на своих ноутбуках, и быстрое решение — опубликовать порт SQL в пуле VPN. Более медленный ответ спрашивает, где должен работать клиентский процесс, потому что прямой доступ и внутренняя рабочая станция дают разные адреса источника, доверие к конечной точке и пути данных. Ни один из них не является автоматически безопасным, и одно лишь членство в VPN ничего не решает. Сравните проекты до того, как появится правило разрешения.

Два пути, два адреса источника

При прямом доступе ноутбук несёт конфигурацию клиента и сам открывает подключение к базе данных. При удалённой рабочей станции ноутбук открывает сеанс рабочего стола, а рабочая станция устанавливает SQL-подключение со своего адреса. Поэтому база данных в первом проекте видит пул VPN или транслированный шлюз, а во втором — адрес рабочей станции. Это различие определяет, какое правило межсетевого экрана и какое право SQL действительно применяются.

Ноутбук по-прежнему управляет удалённым сеансом, поэтому рабочая станция не заменяет аутентификацию пользователя или политику сеансов.

Проверьте, что база данных видит на самом деле

Адрес источника нужно измерять, а не выводить из схемы. Прочитайте его на стороне сервера живого подключения.

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"

Тест связности доказывает, что прослушиватель принимает TCP из этой сети, а запрос доказывает, к какому входу и какой базе данных пришёл сеанс. Чтобы увидеть адрес, записанный сервером, запросите sys.dm_exec_connections для текущего сеанса — он возвращает адрес клиента после любого преобразования. Если это значение — шлюз, а не ноутбук, правило узла для отдельного пользователя не может работать на машине с базой данных. Запишите наблюдаемое значение рядом с выбранным проектом, потому что переподключения и изменения пула его сдвигают.

Откройте прослушиватель и ничего лишнего

Открывайте только ту службу, которая нужна развёртыванию. Знакомый 1433 — это порт экземпляра по умолчанию, а не универсальная константа.

Get-NetTCPConnection -State Listen -LocalPort 1433

Именованные экземпляры часто слушают динамический порт, а SQL Server Browser отвечает на обнаружение по UDP 1434, и эта зависимость — отдельная поверхность атаки, которую нужно обосновать. Закрепление постоянного порта за экземпляром убирает потребность в Browser и делает правила межсетевого экрана стабильными. Сохраните проверки шифрования и сертификатов, которые клиент уже выполняет, вместо того чтобы отключать их ради прохождения теста. Затем выдайте роли базы данных для нагрузки, а не добавляйте всю группу VPN в серверную роль.

Докажите разрешённый путь и запрещённый

Откройте новый сеанс как обычный одобренный пользователь и подтвердите удостоверение сервера, базу данных и требуемую операцию. Затем подтвердите исключение: источник или учётная запись вне политики должны не пройти тот же тест. Для проекта с рабочей станцией проверьте, что ноутбук не может обойти границу, обратившись к базе данных напрямую. Для прямого доступа проверьте, что маршрут и правило источника по-прежнему действуют после переподключения.

Запишите, где работал клиент, какой источник наблюдала база данных и какое правило это разрешило. Это те доказательства, которые запросит следующая проверка.