VPN을 통한 SQL: 직접 클라이언트인가 내부 워크스테이션인가?

팀은 노트북에서 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 그룹을 서버 역할에 추가하는 대신 워크로드에 데이터베이스 역할을 부여하십시오.

허용된 경로와 거부된 경로를 증명하십시오

일반 승인 사용자로 새 세션을 열고 서버 신원, 데이터베이스, 필요한 작업을 확인하십시오. 그다음, 정책 밖의 원본이나 계정이 같은 테스트에서 실패하는지 확인하십시오. 워크스테이션 설계에서는 노트북이 데이터베이스에 직접 도달해 경계를 우회할 수 없음을 확인하십시오. 직접 접속에서는 재연결 후에도 경로와 원본 규칙이 유효함을 확인하십시오.

클라이언트가 어디서 실행되었는지, 데이터베이스가 어느 원본을 보았는지, 어느 규칙이 허용했는지를 기록하십시오. 그것이 다음 검토가 요구할 증거입니다.