SQL Server가 부팅 시 존재하지 않는 VPN 주소에 바인딩됩니다

서비스가 아직 실행 중일 때 실패한 바인딩에 관한 SQL Server 로그 줄을 읽었다면, 충돌이 아니라 부팅 순서 의존성을 찾은 것입니다. 그 조합이 단서입니다. 엔진이 수신하라고 지시받은 주소가 컴퓨터에 존재하기 전에 시작된 것입니다. 로그인 후에 올라오는 VPN 어댑터는 무인 데이터베이스 서비스에 나쁜 전제 조건이므로, 엔진이 보는 순서대로 실패를 추적하십시오.

클라이언트가 아니라 시작 로그에서 시작하십시오

인스턴스 오류 로그를 열고 마지막 줄만이 아니라 네트워크 초기화 주변 항목을 읽으십시오. 엔진은 시도한 주소와 활성화한 프로토콜을 보고하며, 그 기록은 어떤 클라이언트도 연결하기 전의 것입니다. 이제 호스트에 지금 무엇이 있는지 보십시오. 구성된 주소를 소유한 인터페이스가 사용자가 로그인하고 클라이언트를 시작한 후에만 나타난다면, 부팅 시 주소가 없었고 바인딩 실패는 완전히 설명됩니다.

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixOrigin
Get-Content 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\LOG\ERRORLOG' -Tail 40

인스턴스 경로를 설치 환경에 맞게 조정하고 결론을 내리기 전에 인터페이스 목록을 읽으십시오. 존재하지만 잘못된 어댑터가 소유한 주소는 아직 존재하지 않는 주소와 다른 문제입니다.

엔진이 실제로 따르는 바인딩 순서를 따라가십시오

엔진은 수신기 구성을 읽은 다음 운영 체제에 바인딩을 요청합니다. 그 순간 주소가 로컬이 아니면 해당 주소의 바인딩은 실패하지만 인스턴스의 나머지는 정상적으로 계속될 수 있습니다. 그래서 다른 프로토콜이나 다른 주소가 여전히 작동할 수 있고, 그래서 „SQL Server가 다운됐다“는 잘못된 요약입니다. 로그에서 정확한 엔드포인트를 보존하십시오. 주소, 포트, 프로토콜이며, 수정은 셋 중 어느 것이 잘못됐는지에 달려 있습니다.

어댑터가 나타난 후 서비스를 다시 시작하면 보통 수신기가 성공하게 되는데, 그것이 바로 함정입니다. 의존성을 제거하는 대신 증명하며, 터널이 다시 연결될 때마다 연결된 모든 사용자를 끊습니다.

엔진이 읽는 방식으로 수신기를 읽으십시오

SQL Server Configuration Manager에서 인스턴스의 TCP/IP 속성을 열고 개별 주소를 편집하기 전에 Listen All 설정을 확인하십시오. Listen All이 Yes이면 주소별 Enabled 값은 무시되므로, 이를 편집해도 수신기가 사용하는 것은 바뀌지 않습니다. 세 가지를 순서대로 기록하십시오. 서비스하려는 주소, 포트, 수신기가 모든 주소를 대상으로 하는지 하나만 대상으로 하는지입니다. 그런 다음 지원되는 재시작 절차로 변경을 적용하고 다음 시작 로그를 읽어 엔진이 요청한 대로 바인딩했는지 확인하십시오.

모든 주소에서 수신하는 것은 액세스 제어가 아닙니다. 넓은 수신기가 정말로 필요하다면, 접근 가능한 각 인터페이스에는 자체 방화벽과 데이터베이스 권한 결정이 필요하며, 인터넷을 향한 인터페이스도 포함됩니다.

클라이언트에 안정적인 목적지를 제공하십시오

클라이언트는 데이터베이스 호스트가 풀 주소를 입을 필요가 없습니다. 라우팅 설계에서는 서버가 안정적인 사설 주소에서 수신하고 VPN 게이트웨이가 클라이언트 트래픽을 그쪽으로 전달하며 응답을 되돌려 보냅니다.

Test-NetConnection -ComputerName 10.80.0.15 -Port 1433
tracert -d 10.80.0.15

클라이언트가 10.80.0.15에 도달하면 경로가 증명된 것이며 데이터베이스는 해당 클라이언트를 승인하기만 하면 됩니다. 도달하지 못하면 수신기를 다시 건드리기 전에 라우팅과 DNS를 고치십시오. 서버의 바인딩 문제가 클라이언트가 서버를 찾지 못한 이유였던 적은 없습니다. 서버에 가짜 풀 주소를 추가하거나 수신기를 만족시키기 위해 두 번째 기본 게이트웨이를 추가하면 예전 문제 위에 새 네트워크 문제를 만듭니다. 서버 주소 지정은 정적으로 유지하고 터널이 클라이언트를 그쪽으로 데려가게 하십시오.

클라이언트가 사용한 엔드포인트를 확인하십시오

포트 테스트가 아니라 애플리케이션 수준 점검으로 끝내십시오. 애플리케이션이 사용하는 계정으로 클라이언트에서 연결하고 서버 측 연결 세부 정보를 읽으십시오. 세션이 도착한 로컬 주소가 표시됩니다.

sqlcmd -S tcp:10.80.0.15,1433 -Q "SELECT local_net_address, local_tcp_port FROM sys.dm_exec_connections WHERE session_id = @@SPID"

그 주소를 구성한 수신기와 비교하십시오. 불일치는 두 번째 수신기 또는 예기치 않은 곳에서 확인되는 이름을 뜻하며, 다음 재부팅이 대신 수정 사항을 시험하기 전에 둘 다 알아 둘 가치가 있습니다. 그런 다음 로그인한 사용자 없이 호스트를 재부팅하고 바인딩이 성공하는지 확인하십시오. 그 한 번의 테스트가 수리된 수신기와 다음 패치 야간에 실패할 임시 방편의 차이입니다.