이 글에서는 온프레미스 Windows 파일 서버에 Azure 파일 공유를 캐시하는 Azure 파일 동기화의 네트워킹 고려사항에 대해 다룹니다. 직접 Azure Files 배포를 위한 네트워킹 고려사항에 대해서는 Azure Files 네트워킹 고려사항을 참조하세요.
Azure 파일 동기화의 네트워킹은 두 개의 Azure 객체로 구성됩니다: 등록된 서버와 동기화 그룹을 관리하는 Storage Sync Service와 파일 공유를 호스팅하는 Azure 스토리지 계정입니다. 대부분의 경우 기본 인터넷 연결 이상의 특별한 네트워킹 설정은 필요하지 않지만, 프록시 서버, 방화벽, VPN 또는 ExpressRoute 터널링, 프라이빗 엔드포인트, QUIC를 통한 SMB 등을 구성할 수 있습니다.
중요합니다
Azure 파일 동기화는 인터넷 라우팅을 지원하지 않습니다. 기본 네트워크 라우팅 옵션인 Microsoft 라우팅은 Azure 파일 동기화에서 지원됩니다.
Azure 파일 동기화를 사용하여 Windows 파일 서버를 Azure에 연결
온프레미스 Windows 파일 서버와 함께 Azure Files와 Azure 파일 동기화를 설정하고 사용하려면 기본적인 인터넷 연결 외에 Azure에 특별한 네트워킹이 필요하지 않습니다. Azure 파일 동기화를 배포하려면, Azure와 동기화하고 싶은 Windows 파일 서버에 Azure 파일 동기화 에이전트를 설치하세요. Azure 파일 동기화 에이전트는 두 가지 채널을 통해 Azure 파일 공유와 동기화를 달성합니다:
- Azure 파일 공유에 액세스하는 데 사용되는 HTTPS 기반 프로토콜인 FileREST 프로토콜입니다. FileREST 프로토콜은 데이터 전송에 표준 HTTPS를 사용하므로 포트 443에 아웃바운드에 액세스할 수 있어야 합니다. Azure 파일 동기화 SMB 프로토콜을 사용하여 온-프레미스 Windows Server와 Azure 파일 공유 간에 데이터를 전송하지 않습니다.
- 동기화 정보를 교환하는 데 사용되는 HTTPS 기반 프로토콜인 Azure 파일 동기화 동기화 프로토콜, 즉 사용자 환경의 엔드포인트 간에 파일 및 폴더에 대한 버전 정보입니다. 이 프로토콜은 타임스탬프 및 ACL(액세스 제어 목록)과 같은 파일 및 폴더에 대한 메타데이터를 교환하는 데도 사용됩니다.
Azure 파일 동기화 에이전트를 위해 Azure 파일 공유를 SMB로 직접 마운트하는 것은 필수가 아니며, 파일 공유에 대한 직접적인 변경이 최대 24시간 동안 감지되지 않을 수 있기 때문에 권장되지 않습니다. Azure 파일 동기화 없이 파일 공유를 직접 사용하려면 Azure Files 네트워킹 개요를 참조하세요.
Azure 파일 동기화 특별한 네트워킹 구성이 필요하지는 않지만 일부 고객은 다음과 같은 시나리오를 사용하도록 고급 네트워킹 설정을 구성하려고 할 수 있습니다.
- 조직의 프록시 서버 구성과 상호 운용합니다.
- Azure Files 및 Azure 파일 동기화 서비스에 대한 조직의 온-프레미스 방화벽을 엽니다.
- ExpressRoute 또는 VPN(가상 사설망) 연결을 통해 Azure Files 및 Azure 파일 동기화 트래픽을 터널링합니다.
프록시 서버 구성
Azure 파일 동기화는 프록시 서버와 완전히 상호 운용할 수 있지만, Azure 파일 동기화로 환경에 맞는 프록시 엔드포인트 설정을 수동으로 설정해야 합니다. PowerShell과 Azure 파일 동기화 서버 cmdletSet-StorageSyncProxyConfiguration을 사용하세요.
프록시 서버를 사용하여 Azure 파일 동기화를 구성하는 방법에 대한 자세한 내용은 프록시 서버로 Azure 파일 동기화 구성을 참조하세요.
방화벽 및 서비스 태그 구성
보안상의 이유로 많은 조직은 파일 서버를 대부분의 인터넷 위치와 격리합니다. 이러한 환경에서 Azure 파일 동기화를 사용하려면 선택한 Azure 서비스에 대한 아웃바운드 액세스를 허용하도록 방화벽을 구성해야 합니다. 방화벽이 URL 또는 도메인 필터링을 지원한다면, 해당 Azure 서비스를 호스팅하는 필수 클라우드 엔드포인트에 포트 443 아웃바운드 접근을 허용하세요. 그렇지 않은 경우 서비스 태그를 통해 이러한 Azure 서비스의 IP 주소 범위를 검색할 수 있습니다.
Azure 파일 동기화에는 서비스 태그로 식별된 다음 서비스의 IP 주소 범위가 필요합니다.
| 서비스 | 설명 | 서비스 태그 |
|---|---|---|
| Azure 파일 동기화 | 스토리지 동기화 서비스 개체에 표시되는 Azure 파일 동기화 서비스는 Azure 파일 공유와 Windows 파일 서버 간에 데이터를 동기화하는 핵심 활동을 담당합니다. | StorageSyncService |
| Azure Files | Azure 파일 동기화를 통해 동기화된 모든 데이터는 Azure 파일 공유에 저장됩니다. Windows 파일 서버에서 변경된 파일은 Azure 파일 공유로 복제되고 온-프레미스 파일 서버에서 계층화된 파일은 사용자가 요청하면 원활하게 다운로드 됩니다. | Storage |
| Azure 리소스 관리자 | Azure Resource Manager는 Azure용 관리 인터페이스입니다. Azure 파일 동기화 서버 등록 및 지속적인 동기화 서버 작업을 비롯한 모든 관리 호출은 Azure Resource Manager를 통해 수행됩니다. | AzureResourceManager |
| Microsoft Entra ID (마이크로소프트 엔트라 ID) | Microsoft Entra ID(이전의 Azure AD)에는 Storage Sync Service에 대해 서버 등록 권한을 부여하는 데 필요한 사용자 보안 주체와 Azure 파일 동기화가 사용자의 클라우드 리소스에 대한 액세스 권한을 부여받는 데 필요한 서비스 보안 주체가 포함됩니다. | AzureActiveDirectory |
Azure 내에서 Azure 파일 동기화를 사용하는 경우 다른 지역이더라도 네트워크 보안 그룹에서 직접 서비스 태그 이름을 사용하여 해당 서비스에 대한 트래픽을 허용할 수 있습니다. 자세히 알아보려면 네트워크 보안 그룹을 참조하세요.
온-프레미스 Azure 파일 동기화를 사용하는 경우 서비스 태그 API를 사용하여 방화벽의 허용 목록에 대한 특정 IP 주소 범위를 가져올 수 있습니다. 이 정보를 가져오는 방법에는 다음 두 가지가 있습니다.
- 서비스 태그를 지원하는 모든 Azure 서비스에 대한 IP 주소 범위의 현재 목록은 Microsoft 다운로드 센터에서 JSON 문서 형식으로 매주 게시됩니다. 각 Azure 클라우드는 해당 클라우드와 관련된 IP 주소 범위를 포함하는 자체 JSON 문서를 포함합니다.
- 서비스 태그 검색 API(미리 보기)를 사용 하면 현재 서비스 태그 목록을 프로그래밍 방식으로 검색할 수 있습니다. 미리 보기에서 서비스 태그 검색 API는 Microsoft 다운로드 센터에 게시된 JSON 문서에서 반환된 정보 보다 최신 정보가 아닌 정보를 반환할 수 있습니다. 자동화 기본 설정에 따라 API surface를 사용할 수 있습니다.
서비스 태그 API를 사용하여 서비스의 주소를 검색하는 방법에 대한 자세한 내용은 Azure 파일 동기화 IP 주소에 대한 허용 목록을 참조하세요.
가상 개인 네트워크 또는 ExpressRoute를 통해 트래픽 터널링
일부 조직에서는 추가 보안 계층을 위해 또는 Azure와의 통신이 결정적 경로를 따르도록 하기 위해 VPN 또는 ExpressRoute와 같은 네트워크 터널을 통과하기 위해 Azure와의 통신이 필요합니다.
Azure Files 및 Azure 파일 동기화에서 지원하는 온-프레미스 서버 및 Azure 간의 트래픽을 터널링하는 메커니즘은 다음과 같습니다.
Azure VPN Gateway: VPN 게이트웨이는 Azure 가상 네트워크와 온프레미스 같은 대체 위치(예: 온프레미스) 간에 암호화된 트래픽을 인터넷을 통해 전송하는 데 사용하는 특정 유형의 가상 네트워크 게이트웨이입니다. Azure VPN Gateway는 스토리지 계정이나 다른 Azure 리소스와 함께 리소스 그룹에 배포하는 Azure 자원입니다. Azure 파일 동기화는 온프레미스 Windows 파일 서버와 함께 사용하도록 설계되어 있기 때문에 보통 사이트 간 VPN을 사용하지만, 기술적으로는 포인트 투 사이트 VPN을 사용하는 것도 가능합니다.
사이트 간 VPN 연결은 Azure 가상 네트워크와 조직의 온프레미스 네트워크를 연결합니다. 사이트 간 VPN 연결을 통해 조직 네트워크에 호스팅된 VPN 서버나 기기에 대해 한 번만 VPN 연결을 설정할 수 있게 해주며, Azure 파일 공유에 접근해야 하는 모든 클라이언트 기기에 대해 설정하는 것이 아닙니다. 사이트 간 VPN 연결 배포를 단순화하려면 Azure Files에서 사용할 Site-to-Site VPN 구성 항목을 참조하세요.
ExpressRoute: 인터넷을 통과하지 않는 온-프레미스 네트워크와 Azure 간에 정의된 경로(프라이빗 연결)를 만들 수 있습니다. ExpressRoute는 온-프레미스 데이터 센터와 Azure 간에 전용 경로를 제공하기 때문에 네트워크 성능이 주요 고려 사항인 경우 ExpressRoute가 유용할 수 있습니다. ExpressRoute는 조직의 정책 또는 규정 요구 사항에서 클라우드의 리소스에 대한 결정적 경로가 필요한 경우에도 유용한 옵션입니다.
QUIC 위의 SMB
만약 환경에서 포트 445가 차단되어 있다면, VPN이나 ExpressRoute 대신 SMB를 QUIC로 사용할 수 있습니다. SMB over QUIC는 대부분의 조직과 인터넷 서비스 제공업체(ISP)가 HTTPS 트래픽을 지원하기 위해 개방된 포트 443을 통한 QUIC 전송 프로토콜을 사용합니다. 이 기능은 공용 인터넷을 통해 원격으로 파일 공유에 접근하기 위해 일반적으로 필요한 네트워킹 구성을 대부분 제거합니다.
Azure 파일 동기화에서 SMB를 QUIC보다 사용하려면:
- Azure 파일 동기화 서버 엔드포인트는 Azure의 Windows Server Datacenter: Azure Edition 가상 머신에서 실행되어야 합니다.
- 클라이언트는 Windows 11 이상을 실행해야 합니다.
설정 및 구성 세부사항은 SMB over QUIC를 참조하세요.
Azure Files 및 Azure 파일 동기화용 프라이빗 엔드포인트
Azure Files 및 Azure 파일 동기화 스토리지 계정 및 스토리지 동기화 서비스를 통해 제공하는 기본 공용 엔드포인트 외에도 리소스당 하나 이상의 프라이빗 엔드포인트를 가질 수 있는 옵션을 제공합니다. 이 옵션을 통해 VPN이나 ExpressRoute를 통해 온프레미스에서 Azure 파일 공유에 사적으로 안전하게 연결할 수 있으며, Azure 가상 네트워크 내에서 가능합니다. Azure 리소스에 대한 프라이빗 엔드포인트를 만들면 가상 네트워크의 주소 공간 내에서 개인 IP 주소를 가져옵니다. 이는 온-프레미스 Windows 파일 서버가 온-프레미스 네트워크의 전용 주소 공간 내에 있는 IP 주소를 받는 것과 비슷합니다.
개별 프라이빗 엔드포인트는 특정 Azure 가상 네트워크 서브넷과 연결됩니다. 스토리지 계정 및 스토리지 동기화 서비스는 둘 이상의 가상 네트워크에 프라이빗 엔드포인트를 가질 수 있습니다.
프라이빗 엔드포인트를 사용하면 다음 작업을 수행할 수 있습니다.
- 개인 피어링을 통한 VPN 또는 ExpressRoute 연결을 사용하여 온-프레미스 네트워크에서 Azure 리소스에 안전하게 연결합니다.
- Azure Files 및 파일 동기화 대한 퍼블릭 엔드포인트를 사용하지 않도록 설정하여 Azure 리소스를 보호합니다. 기본적으로 프라이빗 엔드포인트를 만들면 퍼블릭 엔드포인트에 대한 연결이 차단되지 않습니다.
- 가상 네트워크(및 피어링 경계)에서 데이터 반출을 차단할 수 있도록 하여 가상 네트워크의 보안을 강화합니다.
프라이빗 엔드포인트를 생성하려면 'Azure 파일 동기화용 프라이빗 엔드포인트 구성'을 참조하세요.
프라이빗 엔드포인트 및 DNS
프라이빗 엔드포인트를 만들 때, Azure는 서브도메인에 privatelink 대응하는 프라이빗 DNS 존도 생성하거나 업데이트합니다. 공용 클라우드 지역의 경우 이러한 DNS 영역은 Azure File용 privatelink.file.core.windows.net과 Azure 파일 동기화용 privatelink.afs.azure.net입니다.
참고
이 문서에서는 core.windows.net Azure 퍼블릭 지역에 대한 스토리지 계정 DNS 접미사를 사용합니다. 이는 21Vianet 클라우드에서 운영하는 Azure 미국 정부 클라우드 및 Microsoft Azure와 같은 Azure 소버린 클라우드에도 적용되며 사용자 환경에 적절한 접미사를 대체합니다.
스토리지 계정과 스토리지 싱크 서비스에 대해 프라이빗 엔드포인트를 만들면, Azure는 각각의 프라이빗 DNS 존에 A 레코드를 생성합니다. Azure는 또한 공개 DNS 항목을 업데이트하여 일반 완전 자격 도메인 이름이 해당 privatelink 이름에 대한 CNAME이 되도록 합니다. 이 구성은 완전 자격화된 도메인 이름이 요청자가 가상 네트워크 내에 있을 때 개인 엔드포인트 IP 주소를 가리키고, 요청자가 가상 네트워크 외부에 있을 때는 공용 엔드포인트 IP 주소를 가리킬 수 있게 합니다.
Azure Files의 경우 각 프라이빗 엔드포인트에는 storageaccount.privatelink.file.core.windows.net 패턴을 따르는 단일 FQDN(정규화된 도메인 이름)이 있으며, 이는 해당 프라이빗 엔드포인트의 프라이빗 IP 주소 하나에 매핑됩니다. Azure 파일 동기화의 경우, 각 프라이빗 엔드포인트에는 Azure 파일 동기화에서 제공하는 네 가지 엔드포인트(관리, 동기화(주), 동기화(보조), 모니터링)에 대해 네 개의 정규화된 도메인 이름(FQDN)이 있습니다. 이러한 엔드포인트에 대한 정규화된 도메인 이름은 일반적으로 이름에 비 ASCII 문자가 포함된 경우를 제외하고는 저장소 동기화 서비스의 이름을 따릅니다. 예를 들어 스토리지 동기화 서비스 이름이 미국 서부 2 지역에서 mysyncservice인 경우 해당 엔드포인트는 mysyncservicemanagement.westus2.afs.azure.net, mysyncservicesyncp.westus2.afs.azure.net, mysyncservicesyncs.westus2.afs.azure.net및 mysyncservicemonitoring.westus2.afs.azure.net가 될 수 있습니다. 스토리지 동기화 서비스에 대한 각 프라이빗 엔드포인트에는 4개의 고유한 IP 주소가 포함됩니다.
Azure 프라이빗 DNS 영역은 프라이빗 엔드포인트가 포함된 가상 네트워크에 연결되어 있으므로 Azure VM에서 PowerShell에서 Resolve-DnsName cmdlet을 호출하여 DNS 구성을 관찰할 수 있습니다(또는 Windows 및 Linux에서는 nslookup).
Resolve-DnsName -Name "storageaccount.file.core.windows.net"
이 예제에서는 storageaccount.file.core.windows.net 스토리지 계정이 프라이빗 엔드포인트의 개인 IP 주소(192.168.0.4)로 확인됩니다.
Name Type TTL Section NameHost
---- ---- --- ------- --------
storageaccount.file.core.windows. CNAME 29 Answer storageaccount.privatelink.file.core.windows.net
net
Name : storageaccount.privatelink.file.core.windows.net
QueryType : A
TTL : 1769
Section : Answer
IP4Address : 192.168.0.4
Name : privatelink.file.core.windows.net
QueryType : SOA
TTL : 269
Section : Authority
NameAdministrator : azureprivatedns-host.microsoft.com
SerialNumber : 1
TimeToZoneRefresh : 3600
TimeToZoneFailureRetry : 300
TimeToExpiration : 2419200
DefaultTTL : 300
온-프레미스에서 동일한 명령을 실행하면 동일한 스토리지 계정 이름이 스토리지 계정의 공용 IP 주소로 확인됩니다. storageaccount.file.core.windows.net은 storageaccount.privatelink.file.core.windows.net에 대한 CNAME 레코드이며, 스토리지 계정을 호스팅하는 Azure 스토리지 클러스터에 대한 CNAME 레코드입니다.
Name Type TTL Section NameHost
---- ---- --- ------- --------
storageaccount.file.core.windows. CNAME 60 Answer storageaccount.privatelink.file.core.windows.net
net
storageaccount.privatelink.file.c CNAME 60 Answer file.par20prdstr01a.store.core.windows.net
ore.windows.net
Name : file.par20prdstr01a.store.core.windows.net
QueryType : A
TTL : 60
Section : Answer
IP4Address : 52.239.194.40
이 구성은 Azure Files와 Azure 파일 동기화가 각 리소스별로 공개 엔드포인트와 하나 이상의 프라이빗 엔드포인트를 모두 노출할 수 있다는 사실을 반영합니다. 리소스의 완전 자격 도메인 이름이 사설 엔드포인트 IP 주소로 해석되도록 하려면 온프레미스 DNS 서버를 구성해야 합니다. 이 과제는 여러 가지 방법으로 수행할 수 있습니다:
- 클라이언트의 hosts 파일을 수정하여 스토리지 계정과 Storage Sync Service의 정규화된 도메인 이름(FQDN)이 원하는 프라이빗 IP 주소로 확인되도록 합니다. 프라이빗 엔드포인트에 액세스해야 하는 모든 클라이언트를 변경해야 하므로 프로덕션 환경에는 권장되지 않습니다. 프라이빗 엔드포인트/리소스(삭제, 수정 등)에 대한 변경 내용은 자동으로 처리되지 않습니다.
- 온-프레미스 서버에서
privatelink.file.core.windows.net및privatelink.afs.azure.net에 대한 DNS 영역을 만들고 Azure 리소스에 대한 A 레코드를 구성합니다. 이는 온-프레미스 환경의 클라이언트가 각 클라이언트를 구성하지 않고도 Azure 리소스를 자동으로 해결할 수 있다는 장점이 있습니다. 그러나 이 솔루션은 변경 내용이 반영되지 않으므로 hosts 파일을 수정하는 것과 유사하게 취약합니다. 이 솔루션은 취약하지만 일부 환경에서는 최선의 선택일 수 있습니다. -
core.windows.net과afs.azure.net영역을 온-프레미스 DNS 서버에서 Azure 프라이빗 DNS 영역으로 전달합니다. Azure 프라이빗 DNS 호스트는 Azure 프라이빗 DNS 영역에 연결된 가상 네트워크 내에서만 액세스할 수 있는 특수 IP 주소(168.63.129.16)를 통해 연결할 수 있습니다. 이 제한을 우회하려면 가상 네트워크 내에서 추가 DNS 서버를 실행하여core.windows.net및afs.azure.net을 해당 Azure 프라이빗 DNS 영역으로 전달하도록 구성할 수 있습니다. 이 구성을 단순화하기 위해 Microsoft는 Azure 가상 네트워크에 DNS 서버를 자동으로 배포하고 원하는 대로 설정하는 PowerShell 명령어를 제공합니다. DNS 전달 설정 방법을 배우려면 'DNS 설정'을 Azure Files 참고하세요.
전송 중 암호화
Azure 파일 동기화 에이전트에서 Azure 파일 공유 또는 스토리지 동기화 서비스로 만들어진 연결은 항상 암호화됩니다. Azure Storage 계정에는 Azure Files(및 스토리지 계정에서 관리되는 다른 Azure Storage 서비스)에 대한 통신을 위해 전송 중인 암호화를 사용하지 않도록 설정하는 설정이 있지만, 이 설정을 사용하지 않도록 설정해도 Azure Files와 통신할 때 Azure 파일 동기화 암호화에 영향을 주지 않습니다. 기본적으로 모든 Azure 스토리지 계정에는 전송 중 암호화가 사용하도록 설정되어 있습니다.
전송 시 암호화에 대한 자세한 내용은 Azure 저장소에서 보안 전송 요구를 참조하세요.