프라이빗 엔드포인트, 같은 서버 이름: Azure SQL 연결 문자열

Private Link는 연결이 도착하는 위치를 바꾸는 것이지 연결의 이름을 바꾸는 것이 아닙니다. Azure SQL Database에서 그 구분이 설계의 전부이며, 논리 서버는 이름을 유지하고, 프라이빗 엔드포인트는 그 이름이 확인되는 네트워크 항목을 제공합니다. 이름을 IP 주소로 바꾸는 것은 TLS, 자격 증명, 도구를 동시에 깨뜨리는 유일한 변경입니다. 두 연결 문자열은 동등해 보이면서 전혀 다르게 동작할 수 있습니다.

orders-db.database.windows.net을 유지하고 클라이언트에 그에 대한 프라이빗 응답을 제공하세요.

이름과 주소는 하는 일이 다릅니다

이름은 SQL 서비스를 식별하며, 인증서와 로그인이 기대하는 것이 바로 그것입니다. 프라이빗 주소는 연결된 가상 네트워크 내부의 네트워크 항목을 제공합니다. 둘을 혼동하면 무언가에 도달하지만 아무것에도 인증하지 않는 연결이 만들어집니다.

Azure SQL에 대한 Microsoft 지침은 클라이언트에 일반 서버 이름을 요구합니다. 직접 IP와 마찬가지로 privatelink 접두사가 붙은 이름도 교환 가능한 로그인 대상이 아닙니다. IP를 받아들이는 도구는 그것을 받아들인 뒤 TLS나 인증에서 실패하며, 이는 실제 실수를 가립니다. 그 실패는 오류의 호스트 이름을 볼 때까지 자격 증명 문제처럼 읽힙니다.

프라이빗 영역이 실제로 바꾸는 것

프라이빗 DNS 영역은 privatelink 네임스페이스 안에 서버의 주소 하나를 기록하고, 그 영역은 이를 사용해야 하는 가상 네트워크에 연결됩니다. 확인은 이동하지만 연결 문자열은 이동하지 않습니다. 아래 모양은 예시이며 공용 영역에 붙여 넣을 레코드가 아닙니다.

Application name:        orders-db.database.windows.net
Private DNS zone:        privatelink.database.windows.net
Resolved private entry:  the approved private endpoint address

그 레코드와 영역 연결을 소유자와 검토 날짜와 함께 인프라로 유지 관리하세요.

같은 출처이고 응답이 다른 두 영역은 정상적인 최종 상태이며 충돌이 아닙니다. 공용 클라이언트는 공용 응답을 유지하고, 프라이빗 클라이언트는 엔드포인트 주소를 받습니다. 주의할 장애 모드는 프라이빗 뷰의 부분 전파로, 한 서브넷은 프라이빗으로 확인되고 다른 서브넷은 조용히 확인되지 않는 상태입니다.

Azure 외부의 클라이언트에는 그 영역으로 들어가는 경로가 필요합니다

VPN 클라이언트는 Azure의 확인자 외부에 있으므로 프라이빗 영역은 하이브리드 경로에서 도달할 수 있어야 합니다. Azure DNS 전달자 또는 Azure DNS Private Resolver가 그 네트워크를 통해 들어오는 쿼리를 처리할 수 있습니다. Microsoft의 지침은 클라이언트가 privatelink 이름을 직접 쿼리한다고 가정하는 대신 해당 공용 서비스 영역을 그 구성으로 전달하는 것입니다. 프라이빗 응답을 확인할 수 없는 클라이언트는 불평 없이 공용 응답으로 되돌아갑니다.

전달 범위를 의도적으로 유지하세요, 사용 중인 공용 영역을 교체하면 교체본에 없는 이름이 깨지기 때문입니다.

ID를 고정하는 순서로 프로비전하세요

단계마다 다른 소유자가 있습니다: 엔드포인트를 만들고 승인하고, VPN 경로를 제공하고, 프라이빗 DNS를 통합한 다음 클라이언트를 일반 서버 이름으로 구성합니다. 경로보다 먼저 DNS를 하면 DNS 장애처럼 보이는 시간 초과가 발생합니다. 클라이언트를 마지막에 하면 한 번에 하나의 변수만 움직입니다. 각 단계에는 관찰 가능한 결과가 있으므로 어느 것도 추측으로 테스트할 필요가 없습니다.

연결된 VPN 아이콘은 그 자체로 프라이빗 대상을 선택하지 않습니다.

프라이빗 엔드포인트가 끄지 않는 것

프라이빗 엔드포인트를 만들었다고 해서 논리 서버에 대한 공용 액세스가 자동으로 비활성화되지는 않습니다. 그것은 별도의 배포 결정이며, 의도한 프라이빗 클라이언트가 작동함을 확인한 뒤에야 합니다. 복구 경로를 유지하고 여전히 공용 진입점을 사용하는 애플리케이션을 고려하세요. 공용 액세스를 먼저 끄는 것은 작동하는 서비스가 깔끔한 감사 추적과 함께 장애가 되는 방식입니다.

서버가 어떤 연결 정책을 사용하는지도 확인하세요.

Redirect는 초기 게이트웨이 연결 후 클라이언트를 노드의 포트로 보내며, 이는 클라이언트 네트워크가 허용해야 하는 것을 바꿉니다. Proxy는 트래픽을 게이트웨이에 유지합니다. 한 포트에서의 성공적인 TCP 핸드셰이크가 전체 로그인 워크플로는 아닙니다.

이것은 Azure SQL Database이며, 자체 연결 모델을 가지고 동등한 프라이빗 엔드포인트 이야기가 없는 SQL Managed Instance가 아닙니다. 두 경우 모두 세 가지를 별도로 레이블링하세요: 이름, 네트워크 항목, 자격 증명. 연결이 어디로 이동하는지 바꾸는 것이 클라이언트가 어떤 서비스와 대화한다고 생각하는지를 바꿔서는 안 됩니다.