VPN을 통한 SQL Server 명명된 인스턴스: 포트 1433이 아니라 검색

대부분의 사람들은 SQL Server 호스트 이름을 완전한 주소로, VPN을 허용되거나 허용되지 않는 것으로 봅니다. 실제로 명명된 인스턴스는 클라이언트가 DNS 이후 두 번째 조회를 하도록 만들며, 터널이 가장 자주 깨뜨리는 부분이 바로 그 조회입니다. 명시적 엔드포인트는 이를 우회하기 때문에 tcp:host,port는 동작하는데 host\INSTANCE는 시간 초과가 날 수 있습니다. 차이는 서비스를 찾는 것과 사용 허가를 받는 것 사이에 있습니다.

신화: 하나의 호스트 이름은 하나의 포트를 의미한다

호스트 이름은 주소로 해석되고, 거기서 역할이 끝납니다. 명명된 인스턴스는 서버가 TCP 포트로 변환해야 하는 인스턴스 이름을 추가하며, 클라이언트는 그것을 추측할 수 없습니다. 포트 1433은 기본 인스턴스의 기본값이지 머신의 모든 인스턴스 속성이 아닙니다. 둘을 같은 것으로 취급하면 전형적인 증상이 생깁니다: ping은 되고 DNS도 되며 1433 스캔은 아무것도 보여주지 않고, 결론은 네트워크가 SQL을 차단한다는 것입니다.

두 번째 가정, 즉 TCP 1433을 열면 충분하다는 가정도 같은 방식으로 무너집니다. 인스턴스가 다른 곳에서 수신한다면 열린 1433은 다른 무언가가 있다는 것만 증명합니다. 포트는 리스너와 일치해야 하며, 리스너는 서버 측 구성 세부 사항이라는 점 이것은 추측할 것이 아니라 물어볼 것입니다.

클라이언트는 명명된 인스턴스에서 실제로 무엇을 하는가

호스트를 해석한 뒤 클라이언트는 UDP 1434로 SQL Server Browser에 검색 요청을 보내고 명명된 인스턴스가 어느 포트를 쓰는지 묻습니다. 브라우저 서비스는 서버 자체의 레지스트리에서 응답하고, 그다음 클라이언트는 그 포트로 TCP 연결을 엽니다. 로그인을 시도하기도 전에 두 프로토콜과 두 포트가 관여합니다.

nslookup sqlhost.corp.example
nc -vzu sqlhost.corp.example 1434
Get-Service -Name SQLBrowser

그래서 UDP만 차단하면 죽은 호스트처럼 보이는 시간 초과가 생깁니다. 브라우저 서비스가 중지되었거나 비활성화되어 있으면 데이터베이스 엔진이 실행 중이고 TCP 포트가 열려 있어도 검색 요청은 답을 받지 못합니다. 인스턴스가 고정 포트로 구성되어 있으면 엔드포인트를 직접 받지 않은 한 클라이언트는 여전히 묻습니다. 이런 각 실패는 애플리케이션 오류 메시지에서 똑같이 보이며, 필요한 수정은 서로 다릅니다.

브라우저 서비스는 검색을 위한 편의 기능이지 데이터베이스가 아닙니다. 중지해도 엔진은 멈추지 않고, 시작해도 인스턴스의 TCP 포트가 열리지 않습니다.

이름이 안 될 때 명시적 엔드포인트가 되는 이유

명시적 엔드포인트는 조회를 순서에서 제거하고, 클라이언트는 지정한 주소와 포트로 곧바로 연결합니다. 나중에 인스턴스가 동적 포트로 재구성되면 포트가 바뀔 수 있으므로, 이것은 자동적인 영구 수정이 아니라 우선 진단입니다. 결론을 내리기 전에 같은 클라이언트와 같은 계정으로 두 형태를 비교하세요.

sqlcmd -S "tcp:sqlhost.corp.example,51433" -U app_login -Q "SELECT @@SERVERNAME"
Test-NetConnection sqlhost.corp.example -Port 51433

명시적 형태가 성공하고 명명된 형태가 실패하면 검색이 빈틈이며, 터널로 UDP 1434를 허용하거나 관리자에게 고정 포트를 지정하고 엔드포인트를 문서화하도록 요청하는 방식으로 막을지를 선택할 수 있습니다. 둘 다 유지 비용이 다른 의도적인 결정입니다. 범위의 모든 포트를 여는 것은 둘 중 어느 것도 아니며, 긴 하루의 끝에 흔히 제안되는 선택지입니다. 선택은 연결 문자열이 있는 곳에 기록하세요.

어느 형태도 동작하지 않으면 문제는 검색의 상류에 있습니다. 브라우저 서비스를 탓하기 전에 리스너, 경로, 그리고 인스턴스가 실제로 쓰는 포트의 접근 규칙을 확인하세요.

검색 이후: 인증과 ID는 별개다

로그인 실패는 시간 초과와 다른 사건이며, 터널이 있다고 해서 VPN ID가 SQL 로그인이 되지는 않습니다. 클라이언트가 올바른 포트에 도달하면 데이터베이스 엔진이 자체 인증과 권한을 적용합니다. 두 단계를 한 티켓에 섞는 것이 검색 문제가 엉뚱한 팀에 배정되는 방식입니다. 무언가를 바꾸기 전에 오류 번호를 읽으세요.

드라이버가 서버 인증서를 검증한다면, 숫자 주소로 연결하는 것이 원래 문제를 해결하는 대신 그 검증을 바꿀 수 있으므로 문서화된 호스트 이름을 유지하세요. 최신 Microsoft 드라이버는 기본적으로 암호화하므로 이름 불일치가 TCP 연결 성공 후 인증서 오류로 나타납니다. 그것은 새로운 실패가 아니라 진전입니다.

버려야 할 신화는 SQL Server 호스트 이름이 완전한 주소라는 것입니다. 그것은 호스트이며, 명명된 인스턴스의 경우 터널이 전달하지 않을 수 있는 조회가 더해집니다. 포트를 지목하고 검색 경로를 지목하면 다음 실패가 어느 계층을 고칠지 알려줄 것입니다.