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 група към сървърна роля.

Докажете разрешения път и забранения

Отворете нова сесия като обикновен одобрен потребител и потвърдете самоличността на сървъра, базата данни и необходимата операция. След това потвърдете изключването: източник или профил извън политиката трябва да се провали на същия тест. За решението с работна станция проверете, че лаптопът не може да заобиколи границата, като достигне базата данни директно. За директния достъп проверете, че маршрутът и правилото за източника все още важат след повторно свързване.

Запишете къде е работил клиентът, кой източник е наблюдавала базата данни и кое правило го е разрешило. Това са доказателствата, които следващият преглед ще поиска.