SQL por VPN: cliente direto ou estação de trabalho interna?

As equipas querem SSMS nos seus portáteis, e a solução rápida é publicar a porta SQL no conjunto VPN. A resposta mais lenta pergunta onde deve correr o processo cliente, porque o acesso direto e uma estação de trabalho interna produzem endereços de origem, confiança do ponto final e caminhos de dados diferentes. Nenhum é automaticamente seguro, e a pertença à VPN por si só não decide nada. Compare os desenhos antes de existir uma regra de permissão.

Dois caminhos, dois endereços de origem

No acesso direto o portátil transporta a configuração do cliente e abre ele mesmo a ligação à base de dados. Numa estação de trabalho remota o portátil abre uma sessão de ambiente de trabalho, e a estação faz a ligação SQL a partir do seu próprio endereço. Por isso a base de dados vê o conjunto VPN ou uma gateway traduzida no primeiro desenho, e o endereço da estação no segundo. Essa diferença decide que regra de firewall e que permissão SQL se aplicam realmente.

O portátil continua a controlar a sessão remota, por isso uma estação de trabalho não substitui a autenticação de utilizador nem a política de sessão.

Verifique o que a base de dados vê realmente

O endereço de origem mede-se, não se deduz de um diagrama. Leia-o do lado do servidor de uma ligação ativa.

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"

O teste de conectividade prova que o ouvinte aceita TCP dessa rede, enquanto a consulta prova a que início de sessão e a que base de dados chegou a sessão. Para ver o endereço que o servidor registou, consulte sys.dm_exec_connections para a sessão atual, que devolve o endereço do cliente após qualquer tradução. Se esse valor for uma gateway e não o portátil, uma regra de anfitrião por utilizador não pode funcionar na máquina da base de dados. Registe o valor observado ao lado do desenho escolhido, porque as reconexões e as mudanças de conjunto deslocam-no.

Abra o ouvinte e nada mais

Abra apenas o serviço de que a implementação precisa. A conhecida 1433 é a porta da instância predefinida, não uma constante universal.

Get-NetTCPConnection -State Listen -LocalPort 1433

As instâncias nomeadas ouvem frequentemente numa porta dinâmica, com o SQL Server Browser a responder à descoberta em UDP 1434, e essa dependência é uma exposição separada que tem de ser justificada. Fixar uma porta estável para a instância remove a necessidade de Browser e torna as regras de firewall estáveis. Mantenha as verificações de cifra e de certificados que o cliente já faz em vez de as desativar para um teste passar. Depois conceda funções de base de dados para a carga de trabalho em vez de adicionar todo o grupo VPN a uma função de servidor.

Prove o caminho permitido e o negado

Abra uma nova sessão como utilizador comum aprovado, e confirme a identidade do servidor, a base de dados e a operação necessária. Depois confirme a exclusão: uma origem ou conta fora da política tem de falhar o mesmo teste. Para o desenho com estação de trabalho, verifique que o portátil não pode contornar a fronteira chegando diretamente à base de dados. Para o acesso direto, verifique que a rota e a regra de origem continuam válidas após uma reconexão.

Registe onde o cliente correu, que origem a base de dados observou e que regra o permitiu. Essa é a evidência que a próxima revisão vai pedir.