Virtual WAN 허브 라우팅 의도 및 라우팅 정책을 구성하는 방법
Virtual WAN 허브 라우팅 의도를 사용하면 트래픽을 Azure Firewall, 네트워크 가상 어플라이언스 또는 Virtual WAN 허브 내에 배포된 SaaS(Software-as-a-Service) 솔루션과 같은 범용 보안 솔루션으로 전송하도록 간단하고 선언적인 라우팅 정책을 설정할 수 있습니다.
배경
라우팅 의도 및 라우팅 정책을 사용하면 가상 허브에 배포된 Azure Firewall, NGFW(차세대 방화벽), NVA(네트워크 가상 어플라이언스) 또는 보안 SaaS(Software-as-a-Service) 솔루션으로 인터넷 바인딩 및 프라이빗(지점 및 사이트 간 VPN, ExpressRoute, Virtual Network 및 네트워크 가상 어플라이언스) 트래픽을 전달하도록 Virtual WAN 허브를 구성할 수 있습니다.
라우팅 정책에는 인터넷 트래픽 정책 및 프라이빗 트래픽 라우팅 정책의 두 가지 유형이 있습니다. 각 Virtual WAN 허브에는 각각 단일 다음 홉 리소스를 포함하는 최대 1개의 인터넷 트래픽 라우팅 정책과 1개의 프라이빗 트래픽 라우팅 정책이 있을 수 있습니다. 프라이빗 트래픽은 분기 및 Virtual Network 주소 접두사를 모두 포함하지만, 라우팅 정책은 두 항목을 라우팅 의도 개념에 속하는 단일 엔터티로 간주합니다.
인터넷 트래픽 라우팅 정책: 인터넷 트래픽 라우팅 정책이 Virtual WAN 허브에 구성된 경우 모든 분기(원격 사용자 VPN(지점 및 사이트 간 VPN), 사이트 간 VPN 및 ExpressRoute) 및 Virtual Network 연결은 인터넷 바인딩 트래픽을 Azure Firewall, 타사 보안 공급자, 네트워크 가상 어플라이언스 또는 라우팅 정책의 일부로 지정된 SaaS 솔루션으로 전달합니다.
즉, Virtual WAN 허브에서 인터넷 트래픽 라우팅 정책이 구성된 경우 Virtual WAN은 기본(0.0.0.0/0) 경로를 모든 스포크, 게이트웨이 및 네트워크 가상 어플라이언스(허브 또는 스포크에 배포됨)에 보급합니다.
프라이빗 트래픽 라우팅 정책: 프라이빗 트래픽 라우팅 정책이 Virtual WAN 허브에 구성된 경우 허브 간 트래픽을 비롯한 Virtual WAN 허브 내/외부의 모든 분기 및 가상 네트워크 트래픽이 다음 홉 Azure 방화벽, 네트워크 가상 어플라이언스 또는 SaaS 솔루션 리소스로 전달됩니다.
즉, 가상 WAN 허브에서 프라이빗 트래픽 라우팅 정책이 구성된 경우 모든 분기-분기, 분기-가상 네트워크, 가상 네트워크 간 및 허브 간 트래픽은 Virtual WAN Hub에 배포된 Azure Firewall, 네트워크 가상 어플라이언스 또는 SaaS 솔루션을 통해 전송됩니다.
사용 사례
다음 섹션에서는 라우팅 정책이 보안 Virtual WAN 허브에 적용되는 두 가지 일반적인 시나리오에 대해 설명합니다.
모든 Virtual WAN Hubs가 보호됩니다(Azure Firewall, NVA 또는 SaaS 솔루션으로 배포됨)
이 시나리오에서는 모든 Virtual WAN 허브가 Azure Firewall, NVA 또는 SaaS 솔루션을 사용하여 배포됩니다. 이 시나리오에서는 각 Virtual WAN 허브에서 인터넷 트래픽 라우팅 정책이나 프라이빗 트래픽 라우팅 정책 또는 두 정책을 모두 구성할 수 있습니다.
허브 1과 허브 2에 프라이빗 및 인터넷 트래픽 모두에 대한 라우팅 정책이 있는 다음 구성을 고려하세요.
허브 1 구성:
- 다음 홉 허브 1 Azure Firewall, NVA 또는 SaaS 솔루션을 사용하는 프라이빗 트래픽 정책
- 다음 홉 허브 1 Azure Firewall, NVA 또는 SaaS 솔루션을 사용하는 인터넷 트래픽 정책
허브 2 구성:
- 다음 홉 허브 2 Azure Firewall, NVA 또는 SaaS 솔루션을 사용하는 프라이빗 트래픽 정책
- 다음 홉 허브 2 Azure Firewall, NVA 또는 SaaS 솔루션을 사용하는 인터넷 트래픽 정책
이러한 구성으로 인해 발생하는 트래픽 흐름은 다음과 같습니다.
참고 항목
기본 경로(0.0.0.0/0)가 허브 간에 전파되지 않으므로 인터넷 트래픽은 허브에 있는 로컬 보안 솔루션을 통해 송신되어야 합니다.
| 보낸 사람 | 수행할 작업 | 허브 1 VNet | 허브 1 분기 | 허브 2 VNet | 허브 2 분기 | 인터넷 |
|---|---|---|---|---|---|---|
| 허브 1 VNet | → | 허브 1 AzFW 또는 NVA | 허브 1 AzFW 또는 NVA | 허브 1 및 2 AzFW, NVA 또는 SaaS | 허브 1 및 2 AzFW, NVA 또는 SaaS | 허브 1 AzFW, NVA 또는 SaaS |
| 허브 1 분기 | → | 허브 1 AzFW, NVA 또는 SaaS | 허브 1 AzFW, NVA 또는 SaaS | 허브 1 및 2 AzFW, NVA 또는 SaaS | 허브 1 및 2 AzFW, NVA 또는 SaaS | 허브 1 AzFW, NVA 또는 SaaS |
| 허브 2 VNet | → | 허브 1 및 2 AzFW, NVA 또는 SaaS | 허브 1 및 2 AzFW, NVA 또는 SaaS | 허브 2 AzFW, NVA 또는 SaaS | 허브 2 AzFW, NVA 또는 SaaS | 허브 2 AzFW, NVA 또는 SaaS |
| 허브 2 분기 | → | 허브 1 및 2 AzFW, NVA 또는 SaaS | 허브 1 및 2 AzFW, NVA 또는 SaaS | 허브 2 AzFW, NVA 또는 SaaS | 허브 2 AzFW, NVA 또는 SaaS | 허브 2AzFW, NVA 또는 SaaS |
보안 및 일반 Virtual WAN 허브를 모두 배포
이 시나리오에서는 WAN에 있는 일부 허브는 보안 Virtual WAN 허브(보안 솔루션이 배포된 허브)가 아닙니다.
허브 1(일반) 및 허브 2(보안)가 Virtual WAN에 배포되는 다음 구성을 고려하세요. 허브 2에는 프라이빗 및 인터넷 트래픽 모두에 대한 라우팅 정책이 있습니다.
허브 1 구성:
- 해당 없음(허브가 Azure Firewall, NVA 또는 SaaS 솔루션과 함께 배포되지 않은 경우 라우팅 정책을 구성할 수 없음)
허브 2 구성:
- 다음 홉 허브 2 Azure Firewall, NVA 또는 SaaS 솔루션을 사용하는 프라이빗 트래픽 정책
- 다음 홉 허브 2 Azure Firewall, NVA 또는 SaaS 솔루션을 사용하는 인터넷 트래픽 정책
이러한 구성으로 인해 발생하는 트래픽 흐름은 다음과 같습니다. 허브 1에 연결된 분기 및 Virtual Network는 기본 경로(0.0.0.0/0)가 허브 간에 전파되지 않으므로 허브에 배포된 보안 솔루션을 통해 인터넷에 액세스할 수 없습니다.
| 보낸 사람 | 수행할 작업 | 허브 1 VNet | 허브 1 분기 | 허브 2 VNet | 허브 2 분기 | 인터넷 |
|---|---|---|---|---|---|---|
| 허브 1 VNet | → | Direct | Direct | 허브 2 AzFW, NVA 또는 SaaS | 허브 2 AzFW, NVA 또는 SaaS | - |
| 허브 1 분기 | → | Direct | Direct | 허브 2 AzFW, NVA 또는 SaaS | 허브 2 AzFW, NVA 또는 SaaS | - |
| 허브 2 VNet | → | 허브 2 AzFW, NVA 또는 SaaS | 허브 2 AzFW, NVA 또는 SaaS | 허브 2 AzFW, NVA 또는 SaaS | 허브 2 AzFW, NVA 또는 SaaS | 허브 2 AzFW, NVA 또는 SaaS |
| 허브 2 분기 | → | 허브 2 AzFW, NVA 또는 SaaS | 허브 2 AzFW, NVA 또는 SaaS | 허브 2 AzFW, NVA 또는 SaaS | 허브 2 AzFW, NVA 또는 SaaS | 허브 2 AzFW, NVA 또는 SaaS |
알려진 제한 사항
- 다음 표에서는 다양한 Azure 환경에서 라우팅 의도의 가용성을 설명합니다.
- 라우팅 의도는 21 Vianet에서 운영하는 Microsoft Azure에서 사용할 수 없습니다.
- Palo Alto Cloud NGFW는 Azure Public에서만 사용할 수 있습니다. Azure Government의 클라우드 NGFW 및 Viacom이 운영하는 Microsoft Azure의 가용성에 대해 Palo Alto Networks에 문의하세요.
- 네트워크 가상 어플라이언스는 모든 Azure Government 지역에서 사용할 수 없습니다. Azure Government의 가용성과 관련하여 NVA 파트너에게 문의하세요.
| 클라우드 환경 | Azure Firewall | 네트워크 가상 어플라이언스 | SaaS 솔루션 |
|---|---|---|---|
| Azure 공용 | 예 | 예 | 예 |
| Azure Government | 예 | 제한적 | 아니요 |
| 21 Vianet에서 운영하는 Microsoft Azure | 아니요 | 아니요 | 아니요 |
- 라우팅 의도는 모든 연결(Virtual Network, 사이트 간 VPN, 지점 및 사이트 간 VPN 및 ExpressRoute)에 대한 경로 테이블 연결 및 전파를 관리하여 라우팅을 간소화합니다. 따라서 사용자 지정 경로 테이블 및 사용자 지정 정책이 포함된 Virtual WAN은 라우팅 의도 구문과 함께 사용할 수 없습니다.
- 암호화된 ExpressRoute(ExpressRoute 회로를 통해 실행하는 사이트 간 VPN 터널)는 Azure Firewall이 VPN 터널 엔드포인트 간의 트래픽(사이트 간 VPN 게이트웨이 프라이빗 IP 및 온-프레미스 VPN 디바이스 프라이빗 IP)을 허용하도록 구성된 경우, 라우팅 의도가 구성된 허브에서 지원됩니다. 필요한 구성에 대한 자세한 내용은 라우팅 의도가 있는 암호화된 ExpressRoute를 참조하세요.
- 다음 연결 사용 사례는 라우팅 의도에서 지원되지 않습니다.
- Virtual Network 연결을 가리키는 defaultRouteTable의 정적 경로는 라우팅 의도와 함께 사용할 수 없습니다. 그러나 BGP 피어링 기능은 사용할 수 있습니다.
- "정적 경로 전파"가 있는 Virtual Network 연결의 정적 경로는 프라이빗 라우팅 정책에 지정된 다음 홉 리소스에 적용되지 않습니다. Virtual Network 연결에 고정 경로를 프라이빗 라우팅 정책 다음 홉에 적용하는 기능 지원이 로드맵에 있습니다.
- SD-WAN 연결 NVA와 동일한 Virtual WAN 허브에 별도의 Firewall NVA 또는 SaaS 솔루션을 배포하는 기능은 현재 로드맵에 있습니다. 라우팅 의도가 다음 홉 SaaS 솔루션 또는 Firewall NVA로 구성되면 SD-WAN NVA와 Azure 간 연결이 영향을 받습니다. 대신 다른 가상 허브에 SD-WAN NVA 및 Firewall NVA이나 SaaS 솔루션을 배포해야 합니다. 허브에 연결된 스포크 Virtual Network의 SD-WAN NVA를 배포하고 가상 허브 BGP 피어링 기능을 활용하는 방법도 있습니다.
- NVA(네트워크 가상 어플라이언스)는 차세대 방화벽 또는 이중 역할 차세대 방화벽 및 SD-WAN NVA인 경우에만 라우팅 의도에 대한 다음 홉 리소스로 지정할 수 있습니다. 현재는 checkpoint, fortinet-ngfw 및 fortinet-ngfw-and-sdwan만이 라우팅 의도에 대한 다음 홉으로 구성할 수 있는 NVA입니다. 다른 NVA를 지정하려고 하면 라우팅 의도 만들기가 실패합니다. 자신의 가상 허브인 > 네트워크 가상 어플라이언스로 이동한 다음 공급업체 필드를 확인하면 NVA 유형을 살펴볼 수 있습니다. Palo Alto Networks Cloud NGFW는 라우팅 의도에 대한 다음 홉으로도 지원되지만 SaaS 솔루션 형식의 다음 홉으로 간주됩니다.
- 여러 ExpressRoute 회로를 Virtual WAN에 연결하고 허브에 배포된 보안 솔루션을 통해 이러한 회로 간에 트래픽을 전송하려는 라우팅 의도 사용자는 지원 사례를 열어 이 사용 사례를 사용하도록 설정할 수 있습니다. 자세한 내용은 ExpressRoute 회로에서 연결을 사용하도록 설정 항목을 참조하세요.
Virtual Network 주소 공간 제한
참고 항목
단일 Virtual WAN 허브에 연결할 수 있는 Virtual Network 주소 공간의 최대 수를 조정할 수 있습니다. Azure 지원 사례를 열어 한도 증가를 요청합니다. 이 제한은 Virtual WAN 허브 수준에서 적용할 수 있습니다. 한도 증가가 필요한 여러 Virtual WAN 허브가 있는 경우 Virtual WAN 배포의 모든 Virtual WAN 허브에 대해 한도 증가를 요청합니다.
라우팅 의도를 사용하는 고객의 경우 단일 Virtual WAN 허브에 직접 연결된 모든 Virtual Network의 최대 주소 공간 수는 400개입니다. 이 제한은 Virtual WAN 배포의 각 Virtual WAN 허브에 개별적으로 적용됩니다. 원격(동일한 Virtual WAN의 다른 Virtual WAN 허브) 허브에 연결된 Virtual Network 주소 공간은 이 제한에 포함되지 않습니다.
허브에 직접 연결된 Virtual Network 주소 공간 수가 제한을 초과하면 Virtual Hub에서 라우팅 의도를 사용하거나 업데이트하지 못합니다. Virtual Network 주소 공간 업데이트와 같은 작업의 결과로 Virtual Network 주소 공간이 제한을 초과하는 라우팅 의도로 이미 구성된 허브의 경우 새로 연결된 주소 공간을 라우팅할 수 없을 수 있습니다.
로컬에 연결된 모든 Virtual Network의 총 주소 공간 수가 문서화된 한도의 90%를 초과하거나 계획된 네트워크 확장 또는 배포 작업이 있는 경우 제한을 초과하여 Virtual Network 주소 공간 수를 늘리는 경우 사전에 제한 증가를 요청합니다.
다음 표에서는 Virtual Network 주소 공간 계산 예제를 제공합니다.
| 가상 허브 | Virtual Network 수 | Virtual Network당 주소 공간 | Virtual Hub에 연결된 총 Virtual Network 주소 공간 수 | 권장 조치 |
|---|---|---|---|---|
| Hub #1 | 200 | 1 | 200 | 아무 작업도 필요하지 않으며 주소 공간 수를 모니터링합니다. |
| Hub #2 | 150 | 3 | 450 | 라우팅 의도를 사용하기 위한 요청 제한 증가입니다. |
| Hub #3 | 370 | 1 | 370 | 제한 증가를 요청합니다. |
다음 Powershell 스크립트를 사용하여 단일 Virtual WAN 허브에 연결된 Virtual Network의 주소 공간 수를 근사화할 수 있습니다. Virtual WAN의 모든 Virtual WAN 허브에 대해 이 스크립트를 실행합니다. 연결된 Virtual Network 주소 공간에 대한 경고를 추적하고 구성할 수 있는 Azure Monitor 메트릭이 로드맵에 있습니다.
사용자 환경과 일치하도록 스크립트에서 Virtual WAN 허브의 리소스 ID를 수정해야 합니다. 테넌트 간 Virtual Network 연결이 있는 경우 Virtual WAN Virtual Network 연결 개체와 연결된 Virtual Network 리소스를 읽을 수 있는 충분한 권한이 있는지 확인합니다.
$hubVNETconnections = Get-AzVirtualHubVnetConnection -ParentResourceId "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/virtualHubs/<virtual hub name>"
$addressSpaceCount = 0
foreach($connection in $hubVNETconnections) {
try{
$resourceURI = $connection.RemoteVirtualNetwork.Id
$RG = ($resourceURI -split "/")[4]
$name = ($resourceURI -split "/")[8]
$VNET = Get-AzVirtualNetwork -Name $name -ResourceGroupName $RG -ErrorAction "Stop"
$addressSpaceCount += $VNET.AddressSpace.AddressPrefixes.Count
}
catch{
Write-Host "An error occurred while processing VNET connected to Virtual WAN hub with resource URI: " -NoNewline
Write-Host $resourceURI
Write-Host "Error Message: " -ForegroundColor Red
Write-Host $_.Exception.Message -ForegroundColor Red
}
finally{
}
}
Write-Host "Total Address Spaces in VNETs connected to this Virtual WAN Hub: " -ForegroundColor Green -NoNewline
Write-Host $addressSpaceCount -ForegroundColor Green
고려 사항
라우팅 의도가 없는 Virtual WAN 허브에서 Azure Firewall을 사용 중인 고객은 Azure Firewall Manager, Virtual WAN 허브 라우팅 포털 또는 다른 Azure 관리 도구(PowerShell, CLI, REST API)를 이용해 라우팅 의도를 사용하도록 설정할 수 있습니다.
라우팅 의도를 사용하도록 설정하기 전에 다음을 고려해야 합니다.
- 라우팅 의도는 다음 홉 Virtual Network 연결이 있는 defaultRouteTable에 사용자 지정 경로 테이블과 정적 경로가 없는 허브에서만 구성할 수 있습니다. 자세한 내용은 필수 구성 요소를 참조하세요.
- 라우팅 의도를 사용하도록 설정하기 전에 게이트웨이, 연결 및 경로 테이블의 복사본을 저장합니다. 시스템은 이전 구성을 자동으로 저장하고 적용하지 않습니다. 자세한 내용은 롤백 전략을 참조하세요.
- 라우팅 의도는 defaultRouteTable의 정적 경로를 변경합니다. Azure 포털 최적화 때문에, REST, CLI 또는 PowerShell을 사용하여 라우팅 의도를 구성하면 라우팅 의도 구성 후 defaultRouteTable의 상태가 달라질 수 있습니다. 자세한 내용은 고정 경로를 참조하세요.
- 라우팅 의도를 사용하도록 설정하면 온-프레미스에 대한 접두사 보급이 영향을 받습니다. 자세한 내용은 접두사 보급을 참조하세요.
- 지원 사례를 열어 허브의 Firewall 어플라이언스를 통한 ExpressRoute 회로에서의 연결을 사용하도록 설정할 수 있습니다. 이 연결 패턴을 사용하도록 설정하면 ExpressRoute 회로에 보급된 접두사가 수정됩니다. 자세한 내용은 ExpressRoute 정보를 참조하세요.
- 라우팅 의도는 허브에 배포된 보안 어플라이언스를 통해 허브 간 트래픽 검사를 사용하도록 설정하는 Virtual WAN의 유일한 메커니즘입니다. 또한 허브 간 트래픽 검사에서는 Virtual WAN 허브에 배포된 보안 어플라이언스 간에 트래픽이 대칭적으로 라우팅되도록 모든 허브에서 라우팅 의도를 사용하도록 설정해야 합니다.
- 라우팅 의도는 Virtual Network 및 온-프레미스 트래픽을 라우팅 정책에 지정된 다음 홉 리소스로 보냅니다. Virtual WAN은 구성된 라우팅 정책에 따라 온-프레미스 및 Virtual Network 트래픽을 라우팅하도록 기본 Azure 플랫폼을 프로그래밍하고 Virtual Hub 라우터를 통해 트래픽을 처리하지 않습니다. 라우팅 의도를 통해 라우팅된 패킷은 라우터에서 처리되지 않으므로 라우팅 의도로 구성된 허브에서 데이터 평면 패킷 전달을 위해 추가 라우팅 인프라 단위 를 할당할 필요가 없습니다. 그러나 Virtual WAN 허브에 연결된 Virtual Network의 Virtual Machines 수에 따라 추가 라우팅 인프라 단위를 할당해야 할 수 있습니다.
- 라우팅 의도를 사용하면 프라이빗 및 인터넷 라우팅 정책에 대해 서로 다른 다음 홉 리소스를 구성할 수 있습니다. 예를 들어 허브의 Azure Firewall에 대한 프라이빗 라우팅 정책의 다음 홉을 설정하고 인터넷 라우팅 정책의 다음 홉을 허브의 NVA 또는 SaaS 솔루션으로 설정할 수 있습니다. SaaS 솔루션 및 방화벽 NVA는 Virtual WAN 허브의 동일한 서브넷에 배포되므로 동일한 허브에 방화벽 NVA를 사용하여 SaaS 솔루션을 배포하면 수평 스케일 아웃에 사용할 수 있는 IP 주소가 적기 때문에 SaaS 솔루션의 수평 확장성에 영향을 줄 수 있습니다. 또한 각 Virtual WAN 허브에 최대 하나의 SaaS 솔루션을 배포할 수 있습니다.
필수 조건
라우팅 의도 및 정책을 사용하도록 설정하려면 가상 허브가 아래 필수 조건을 충족해야 합니다.
- 가상 허브를 이용해 배포된 사용자 지정 경로 테이블이 없습니다. 존재하는 경로 테이블은 noneRouteTable과 defaultRouteTable 뿐입니다.
- 다음 홉 Virtual Network 연결이 있는 정적 경로가 없습니다. 다음 홉 Azure Firewall이 있는 defaultRouteTable에 정적 경로가 존재할 수 있습니다.
라우팅 의도를 구성하는 옵션은 위의 요구 사항을 충족하지 않는 허브에는 회색으로 표시됩니다.
Azure Firewall Manager에서 라우팅 의도(허브 간 옵션 사용)를 사용하는 경우 추가 요구 사항이 있습니다.
- Azure Firewall Manager가 만든 경로는 private_traffic, internet_traffic 또는 all_traffic이라는 명명 규칙을 따릅니다. 따라서 defaultRouteTable에 있는 모든 경로는 이 규칙을 따라야 합니다.
롤백 전략
참고 항목
라우팅 의도 구성이 허브에서 완전히 제거되면 허브에 대한 모든 연결이 기본 레이블(Virtual WAN의 'all' defaultRouteTables에 적용됨)으로 전파되도록 설정됩니다. 따라서 Virtual WAN에서 라우팅 의도를 구현을 고려할 때 기본 구성으로 되돌리고 싶다면, 적용할 기존 구성(게이트웨이, 연결, 경로 테이블)의 사본을 저장해야 합니다. 시스템은 이전 구성을 자동으로 복원하지 않습니다.
라우팅 의도는 허브에 있는 모든 연결의 경로 연결 및 전파를 관리하여 라우팅과 구성을 간소화합니다.
다음 표에서는 라우팅 의도가 구성된 후 모든 연결의 연결된 경로 테이블과 전파된 경로 테이블에 대해 설명합니다.
| 라우팅 의도 구성 | 연결된 경로 테이블 | 전파된 경로 테이블 |
|---|---|---|
| 인터넷 | defaultRouteTable | 기본 레이블(Virtual WAN에 있는 모든 허브의 defaultRouteTable) |
| 프라이빗 | defaultRouteTable | noneRouteTable |
| Internet and Private | defaultRouteTable | noneRouteTable |
defaultRouteTable의 정적 경로
다음 섹션에서는 허브에서 라우팅 의도를 사용하도록 설정할 때 라우팅 의도가 defaultRouteTable의 정적 경로를 관리하는 방법을 설명합니다. 라우팅 의도가 defaultRouteTable에 수행한 수정은 되돌릴 수 없습니다.
라우팅 의도를 제거하면 이전 구성을 수동으로 복원해야 합니다. 따라서 라우팅 의도를 사용하도록 설정하기 전에 구성의 스냅샷 저장하는 것이 좋습니다.
Azure Firewall Manager 및 Virtual WAN 허브 포털
허브에서 라우팅 의도를 사용하도록 설정하면, 구성된 라우팅 정책에 해당하는 정적 경로가 defaultRouteTable에 자동으로 생성됩니다. 이러한 경로는 다음과 같습니다.
| 경로 이름 | 접두사 | 다음 홉 리소스 |
|---|---|---|
| _policy_PrivateTraffic | 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 | Azure Firewall |
| _policy_PublicTraffic | 0.0.0.0/0 | Azure Firewall |
참고 항목
0.0.0.0/0 또는 RFC1918 슈퍼넷(10.0.0.0/8, 192.168.0.0/16 및 172.16.0.0/12)과 정확히 일치하지 않는 접두사를 포함하는 defaultRouteTable의 모든 정적 경로는 private_traffic이라는 단일 정적 경로로 자동으로 통합됩니다. RFC1918 슈퍼넷 또는 0.0.0.0/0과 일치하는 defaultRouteTable의 접두사는 정책 유형에 관계없이 라우팅 의도가 구성되면 항상 자동으로 제거됩니다.
예를 들어 라우팅 의도를 구성하기 전에 defaultRouteTable에 다음 경로가 있는 시나리오를 고려해 보세요.
| 경로 이름 | 접두사 | 다음 홉 리소스 |
|---|---|---|
| private_traffic | 192.168.0.0/16, 172.16.0.0/12, 40.0.0.0/24, 10.0.0.0/24 | Azure Firewall |
| to_internet | 0.0.0.0/0 | Azure Firewall |
| additional_private | 10.0.0.0/8, 50.0.0.0/24 | Azure Firewall |
이 허브에서 라우팅 의도를 사용하도록 설정하면 defaultRouteTable의 다음 종료 상태가 발생합니다. RFC1918 또는 0.0.0.0/0이 아닌 모든 접두사는 private_traffic이라는 단일 경로로 통합됩니다.
| 경로 이름 | 접두사 | 다음 홉 리소스 |
|---|---|---|
| _policy_PrivateTraffic | 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 | Azure Firewall |
| _policy_PublicTraffic | 0.0.0.0/0 | Azure Firewall |
| private_traffic | 40.0.0.0/24, 10.0.0.0/24, 50.0.0.0/24 | Azure Firewall |
기타 메서드(PowerShell, REST, CLI)
포털이 아닌 메서드를 사용하여 라우팅 의도를 만들면 대응하는 경로 정책이 defaultRouteTable에 자동으로 생성되고 0.0.0.0/0 또는 RFC1918 슈퍼넷(10.0.0.0/8, 192.168.0.0/16 or 172.16.0.0/12)과 정확히 일치하는 정적 경로의 접두사가 제거됩니다. 그러나 다른 정적 경로는 자동으로 통합되지 않습니다 .
예를 들어 라우팅 의도를 구성하기 전에 defaultRouteTable에 다음 경로가 있는 시나리오를 고려해 보세요.
| 경로 이름 | 접두사 | 다음 홉 리소스 |
|---|---|---|
| firewall_route_ 1 | 10.0.0.0/8 | Azure Firewall |
| firewall_route_2 | 192.168.0.0/16, 10.0.0.0/24 | Azure Firewall |
| firewall_route_3 | 40.0.0.0/24 | Azure Firewall |
| to_internet | 0.0.0.0/0 | Azure Firewall |
다음 표에는 라우팅 의도 생성이 성공한 후 defaultRouteTable의 최종 상태가 나와 있습니다. firewall_route_1과 to_internet은 이러한 경로의 접두사가 10.0.0.0/8과 0.0.0.0/0 뿐이었기 때문에 자동으로 제거되었습니다. 접두사가 RFC1918 집계 접두사이므로 192.168.0.0/16을 제거하도록 firewall_route_2가 수정되었습니다.
| 경로 이름 | 접두사 | 다음 홉 리소스 |
|---|---|---|
| _policy_PrivateTraffic | 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 | Azure Firewall |
| _policy_PublicTraffic | 0.0.0.0/0 | Azure Firewall |
| firewall_route_2 | 10.0.0.0/24 | Azure Firewall |
| firewall_route_3 | 40.0.0.0/24 | Azure Firewall |
온-프레미스에 대한 접두사 보급
다음 섹션에서는 라우팅 의도가 가상 허브에 구성된 후 Virtual WAN이 온-프레미스로 경로를 보급하는 방법을 설명합니다.
인터넷 라우팅 정책
참고 항목
0.0.0.0/0 기본 경로는 가상 허브에서 보급되지 않습니다.
가상 허브에서 인터넷 라우팅 정책을 사용하도록 설정하면, 기본 경로 전파 또는 인터넷 보안 사용 설정 플래그가 true로 설정된 허브에 대한 모든 연결(Virtual Network ExpressRoute, 사이트 간 VPN, 지점 및 사이트 간 VPN, 허브의 NVA 및 BGP 연결)에 0.0.0.0/0 기본 경로가 보급됩니다. 기본 경로를 학습하지 않아야 하는 모든 연결에는 이 플래그를 false로 설정해도 됩니다.
프라이빗 라우팅 정책
프라이빗 라우팅 정책으로 가상 허브를 구성하면 Virtual WAN은 다음과 같은 방식으로 로컬 온-프레미스 연결에 경로를 보급합니다.
- 로컬 허브의 Virtual Network, ExpressRoute, 사이트 간 VPN, 지점 및 사이트 간 VPN, 허브 내 NVA 또는 현재 허브에 연결된 BGP 연결에서 학습한 접두사에 해당하는 경로입니다.
- 원격 허브 Virtual Network, ExpressRoute, 사이트 간 VPN, 지점 및 사이트 간 VPN, 허브 내 NVA 또는 프라이빗 라우팅 정책이 구성된 BGP 연결에서 학습한 접두사에 해당하는 경로입니다.
- 원격 허브 Virtual Network, ExpressRoute, 사이트 및 사이트 간의 VPN, 지점 및 사이트 간의 VPN, 허브 내 NVA와 라우팅 의도가 구성되지 않고 원격 연결이 로컬 허브의 defaultRouteTable로 전파되는 BGP 연결에서 학습된 접두사에 해당하는 경로입니다.
- Global Reach를 사용하도록 설정하지 않으면 한 ExpressRoute 회로에서 학습한 접두사가 다른 ExpressRoute 회로에 보급되지 않습니다. 허브에 배포된 보안 솔루션을 통한 ExpressRoute에서 ExpressRoute로의 전송을 사용하도록 설정하려면 지원 사례를 여세요. 자세한 내용은 ExpressRoute 회로에서 연결을 사용하도록 설정 항목을 참조하세요.
주요 라우팅 시나리오
다음 섹션에서는 Virtual WAN 허브에서 라우팅 의도를 구성할 때의 몇 가지 주요 라우팅 시나리오 및 라우팅 동작에 대해 설명합니다.
라우팅 의도를 사용한 ExpressRoute 회로 간의 전송 연결
Virtual WAN 내 ExpressRoute 회로 간의 전송 연결은 두 가지 구성을 통해 제공됩니다. 두 구성은 호환되지 않으므로 고객은 두 ExpressRoute 회로 간의 전송 연결을 지원하기 위해 하나의 구성 옵션을 선택해야 합니다.
참고 항목
프라이빗 라우팅 정책을 사용하여 허브의 Firewall 어플라이언스를 통해 ExpressRoute 간 전송 연결을 사용하도록 설정하려면, Microsoft 지원에서 지원 사례를 여세요. 이 옵션은 Global Reach와 호환되지 않으며 Virtual WAN에 연결된 모든 ExpressRoute 회로 간에 적절한 전송 라우팅을 보장하기 위해 Global Reach를 사용하지 않도록 설정해야 합니다.
- ExpressRoute Global Reach: ExpressRoute Global Reach를 사용하면 Global Reach 지원 회로 두 개가 가상 허브를 전송하지 않고 서로 직접 트래픽을 보낼 수 있습니다.
- 라우팅 의도 프라이빗 라우팅 정책: 프라이빗 라우팅 정책을 구성하면 두 ExpressRoute 회로가 허브에 배포된 보안 솔루션을 통해 서로 트래픽을 보낼 수 있습니다.
라우팅 의도 프라이빗 라우팅 정책을 사용한, 허브의 방화벽 어플라이언스를 통한 ExpressRoute 회로 간 연결은 다음 구성에서 사용할 수 있습니다.
- 두 ExpressRoute 회로가 동일한 허브에 연결되고 프라이빗 라우팅 정책이 해당 허브에서 구성됩니다.
- ExpressRoute 회로는 서로 다른 허브에 연결되며 프라이빗 라우팅 정책은 두 허브에서 모두 구성됩니다. 따라서 두 허브 모두에 보안 솔루션이 배포되어야 합니다.
ExpressRoute를 사용한 라우팅 고려 사항
참고 항목
아래 라우팅 고려 사항은 허브의 보안 어플라이언스 통한 ExpressRoute 간 연결을 허용하기 위해 Microsoft 지원에서 사용하도록 설정한 구독의 모든 가상 허브에 적용됩니다.
가상 허브에 배포된 방화벽 어플라이언스 사용하여 ExpressRoute 회로 간 전송 연결을 사용하도록 설정한 후에는, 경로가 ExpressRoute 온-프레미스에 보급되는 방식에서 다음과 같은 동작 변경을 예상할 수 있습니다.
- Virtual WAN은 RFC1918 집계 접두사(10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12)를 ExpressRoute에 연결된 온-프레미스에 자동으로 보급합니다. 이러한 집계 경로는 이전 섹션에서 설명한 경로에 더해 보급됩니다.
- Virtual WAN은 defaultRouteTable의 모든 정적 경로를 ExpressRoute 회로에 연결된 온-프레미스에 자동으로 보급합니다. 즉, Virtual WAN은 프라이빗 트래픽 접두사 텍스트 상자에 지정된 경로를 온-프레미스에 보급합니다.
이러한 경로 보급 변경 때문에, ExpressRoute에 연결된 온-프레미스는 RFC1918 집계 주소 범위(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)에 대한 정확한 주소 범위를 보급할 수 없습니다. 프라이빗 트래픽 텍스트 상자에서 슈퍼넷 및 접두사를 집계하는 대신 더 구체적인 서브넷(RFC1918 범위 내)을 보급하는지 확인합니다.
또한 ExpressRoute 회로가 RFC1918 아닌 접두사를 Azure에 보급하는 경우 프라이빗 트래픽 접두사 텍스트 상자에 입력한 주소 범위가 ExpressRoute 보급 경로보다 덜 구체적인지 확인합니다. 예를 들어 ExpressRoute 회로가 온-프레미스에서 40.0.0.0/24를 보급하는 경우 프라이빗 트래픽 접두사 텍스트 상자에 /23 CIDR 범위 이상을 입력합니다(예: 40.0.0.0/23).
허브에 배포된 보안 어플라이언스를 통해 ExpressRoute에서 ExpressRoute 간 전송 연결을 사용하도록 설정하여 다른 온-프레미스(사이트 간 VPN, 지점 및 사이트 간 VPN, NVA)로의 라우팅 광고는 영향을 받지 않습니다.
암호화된 ExpressRoute
암호화된 ExpressRoute(ExpressRoute 회로를 통해 실행되는 사이트 간 VPN 터널)를 라우팅 의도 프라이빗 라우팅 정책과 함께 사용하려면, Virtual WAN 사이트 간 VPN Gateway(원본)와 온-프레미스 VPN 디바이스(대상)의 터널 개인 IP 주소 간 트래픽을 허용하도록 방화벽 규칙을 구성해야 합니다. 방화벽 디바이스에서 심층 패킷 검사를 사용하는 고객의 경우 이러한 개인 IP 간의 트래픽을 딥 패킷 검사에서 제외하는 것이 좋습니다.
VPN 구성을 다운로드하고 vpnSiteConnections -> gatewayConfiguration -> IPAddresses를 확인하면 Virtual WAN 사이트 간 VPN Gateway의 터널 프라이빗 IP 주소를 얻을 수 있습니다. IPAddresses 필드에 나열된 IP 주소는 ExpressRoute를 통해 VPN 터널을 종료하는 데 사용하는 사이트 간 VPN Gateway의 각 인스턴스에 할당된 프라이빗 IP 주소입니다. 아래 예제에서 게이트웨이의 터널 IP는 192.168.1.4 및 192.168.1.5입니다.
"vpnSiteConnections": [
{
"hubConfiguration": {
"AddressSpace": "192.168.1.0/24",
"Region": "South Central US",
"ConnectedSubnets": [
"172.16.1.0/24",
"172.16.2.0/24",
"172.16.3.0/24",
"192.168.50.0/24",
"192.168.0.0/24"
]
},
"gatewayConfiguration": {
"IpAddresses": {
"Instance0": "192.168.1.4",
"Instance1": "192.168.1.5"
},
"BgpSetting": {
"Asn": 65515,
"BgpPeeringAddresses": {
"Instance0": "192.168.1.15",
"Instance1": "192.168.1.12"
},
"CustomBgpPeeringAddresses": {
"Instance0": [
"169.254.21.1"
],
"Instance1": [
"169.254.21.2"
]
},
"PeerWeight": 0
}
}
온-프레미스 디바이스가 VPN 종료에 사용하는 프라이빗 IP 주소는 VPN 사이트 링크 연결의 일부로 지정된 IP 주소입니다.
위의 샘플 VPN 구성과 VPN 사이트를 사용하여, 다음 트래픽을 허용하는 방화벽 규칙을 만듭니다. VPN Gateway IP는 원본 IP여야 하며 온-프레미스 VPN 디바이스는 구성된 규칙의 대상 IP여야 합니다.
| 규칙 매개 변수 | 값 |
|---|---|
| 원본 IP | 192.168.1.4 및 192.168.1.5 |
| 원본 포트 | * |
| 대상 IP | 10.100.0.4 |
| 대상 포트 | * |
| 프로토콜 | ANY |
암호화된 ExpressRoute의 성능
암호화된 ExpressRoute를 사용하여 프라이빗 라우팅 정책을 구성하면 허브에 배포된 다음 홉 보안 어플라이언스를 통해 VPN ESP 패킷이 라우팅됩니다. 따라서 양방향(온-프레미스에서 인바운드 및 Azure에서 아웃바운드)의 암호화된 ExpressRoute 최대 VPN 터널 처리량 1Gbps를 기대할 수 있습니다. 최대 VPN 터널 처리량을 달성하려면 다음 배포 최적화를 고려하세요.
- Azure Firewall Standard 또는 Azure Firewall Basic 대신 Azure Firewall Premium을 배포합니다.
- Azure Firewall이 Azure Firewall 정책에서 가장 높은 우선 순위를 갖도록 하여 VPN 터널 엔드포인트(위 예제에서는 192.168.1.4 및 192.168.1.5) 간의 트래픽을 허용하는 규칙을 먼저 처리해야 합니다. Azure Firewall 규칙 처리 논리에 대한 자세한 내용은 Azure Firewall 규칙 처리 논리를 참조하세요.
- VPN 터널 엔드포인트 간의 트래픽에 대한 딥 패킷을 끕니다. 심층 패킷 검사에서 트래픽을 제외하도록 Azure Firewall 구성하는 방법에 대한 자세한 내용은 IDPS 바이패스 목록 설명서를 참조하세요.
- 성능을 최대화하기 위해 IPSEC 암호화 및 무결성 모두에 GCMAES256 사용하도록 VPN 디바이스를 구성합니다.
이중 역할 연결 및 방화벽 NVA를 위해 NVA 인스턴스로 직접 라우팅
참고 항목
Virtual WAN에서 프라이빗 라우팅 정책과 함께 사용되는 이중 역할 NVA로의 직접 라우팅은 Virtual WAN 허브에 배포된 NVA에서 BGP를 통해 학습된 경로와 Virtual Network 간의 트래픽에만 적용됩니다. NVA에 연결된 온-프레미스에 대한 ExpressRoute 및 VPN 전송 연결은 NVA 인스턴스로 직접 라우팅되지 않고 대신 이중 역할 NVA의 부하 분산 장치를 통해 라우팅됩니다.
특정 네트워크 가상 어플라이언스는 동일한 디바이스에서 SD-WAN(연결) 및 NGFW(보안) 기능을 모두 가질 수 있습니다. 이러한 NVA는 이중 역할 NVA로 간주됩니다. NVA가 NVA 파트너의 이중 역할 NVA인지 여부를 확인합니다.
프라이빗 라우팅 정책이 이중 역할 NVA에 대해 구성된 경우 Virtual WAN은 해당 Virtual WAN 허브의 NVA 디바이스에서 학습한 경로를 NVA 내부 Load Balancer가 아닌 NVA 인스턴스로 다음 홉을 사용하여 Virtual WAN의 다른 Virtual Hubs뿐만 아니라 직접 연결된(로컬) 가상 네트워크에 자동으로 보급합니다.
NVA의 한 인스턴스만 Virtual WAN에 대한 특정 접두사 경로를 보급하는 활성-수동 NVA 구성의 경우(또는 인스턴스 중 하나에서 학습된 경로의 AS-PATH 길이가 항상 가장 짧음) Virtual WAN은 Azure Virtual Network의 아웃바운드 트래픽이 항상 활성(또는 기본 설정) NVA 인스턴스로 라우팅되도록 합니다.
활성-활성 NVA 구성(여러 NVA 인스턴스가 동일한 AS-PATH 길이로 동일한 접두사를 보급)의 경우 Azure에서 온-프레미스로 트래픽을 라우팅하기 위해 ECMP를 자동으로 수행합니다. Azure의 소프트웨어 정의 네트워킹 플랫폼은 흐름 수준 대칭을 보장하지 않습니다. 즉, Azure로의 인바운드 흐름과 Azure의 아웃바운드 흐름은 NVA의 다른 인스턴스에 착륙할 수 있습니다. 그러면 상태 저장 방화벽 검사에서 삭제되는 비대칭 라우팅이 발생합니다. 따라서 NVA가 비대칭 전달을 지원하거나 세션 공유/동기화를 지원할 수 없는 한 NVA가 이중 역할 NVA로 동작하는 활성-활성 연결 패턴을 사용하지 않는 것이 좋습니다. NVA가 비대칭 전달 또는 세션 상태 공유/동기화를 지원하는지 여부에 대한 자세한 내용은 NVA 공급자에게 문의하세요.
Azure Portal 통한 라우팅 의도 구성
라우팅 의도 및 라우팅 정책은 Azure Firewall Manager나 Virtual WAN 포털을 사용하여 Azure Portal을 통해 구성할 수 있습니다. Azure Firewall Manager 포털을 사용하면 다음 홉 리소스 Azure Firewall을 이용해 라우팅 정책을 구성할 수 있습니다. Virtual WAN 포털을 사용하면 다음 홉 리소스 Azure Firewall을 이용해, 그리고 가상 허브 또는 SaaS 솔루션 내에 배포된 네트워크 가상 어플라이언스를 사용하여 라우팅 정책을 구성할 수 있습니다.
Virtual WAN 보안 허브에서 Azure Firewall을 사용하는 고객은 Azure Firewall Manager의 '허브 간 사용 설정'을 '사용'으로 설정하여 라우팅 의도를 사용하거나 Virtual WAN 포털을 사용하여 Azure Firewall을 라우팅 의도 및 정책에 대한 다음 홉 리소스로 직접 구성할 수 있습니다. 두 포털 환경의 구성은 동일하며, Azure Firewall Manager의 변경 사항은 Virtual WAN 포털에 자동으로 반영되며 그 반대의 경우도 마찬가지입니다.
Azure Firewall Manager를 통한 라우팅 의도 및 정책 구성
아래 단계에서는 Azure Firewall Manager를 사용하여 가상 허브에서 라우팅 의도와 라우팅 정책을 구성하는 방법을 설명합니다. Azure Firewall Manager는 Azure Firewall 유형의 다음 홉 리소스만 지원합니다.
라우팅 정책을 구성하려는 Virtual WAN 허브로 이동합니다.
보안 아래에서 보안 가상 허브 설정을 선택한 다음, Azure Firewall Manager에서 이 보안 가상 허브에 대한 보안 공급자 및 경로 설정 관리를 선택합니다.
메뉴에서 라우팅 정책을 구성하려는 허브를 선택합니다.
설정에서 보안 구성을 선택합니다.
인터넷 트래픽 라우팅 정책을 구성하려면 인터넷 트래픽 드롭다운에서 Azure Firewall 또는 관련 인터넷 보안 공급자를 선택합니다. 그렇지 않은 경우 없음을 선택합니다.
Azure Firewall을 통해 프라이빗 트래픽 라우팅 정책(분기 트래픽 및 Virtual Network 트래픽용)을 구성하려면 프라이빗 트래픽 드롭다운에서 Azure Firewall을 선택합니다. 그렇지 않은 경우 Azure Firewall 무시를 선택합니다.
프라이빗 트래픽 라우팅 정책을 구성하고 비 IANA RFC1918 접두사를 보급하는 분기 또는 가상 네트워크가 있는 경우 프라이빗 트래픽 접두사를 선택하고 표시되는 텍스트 상자에 비 IANA RFC1918 접두사 범위를 지정합니다. 완료를 선택합니다.
허브 간을 선택하여 사용으로 설정합니다. 이 옵션을 사용하도록 설정하면 라우팅 정책이 이 Virtual WAN 허브의 라우팅 의도에 적용됩니다.
저장을 선택합니다.
라우팅 정책을 구성하려는 다른 보안 Virtual WAN 허브에 대해 2~8단계를 반복합니다.
이제 테스트 트래픽을 보낼 준비가 되었습니다. 원하는 보안 구성에 따라 트래픽을 허용/거부하도록 방화벽 정책이 적절하게 구성되어 있는지 확인하세요.
Virtual WAN 포털을 통한 라우팅 의도 및 정책 구성
아래 단계에서는 Virtual WAN 포털을 사용하여 가상 허브에서 라우팅 의도와 라우팅 정책을 구성하는 방법을 설명합니다.
사전 요구 사항 섹션의 3단계에서 확인 이메일에 제공된 사용자 지정 포털 링크에서 라우팅 정책을 구성할 Virtual WAN 허브로 이동합니다.
라우팅에서 라우팅 정책을 선택합니다.
(분기 및 Virtual Network 트래픽을 대상으로) 프라이빗 트래픽 라우팅 정책을 구성하려면 프라이빗 트래픽에서 Azure Firewall, 네트워크 가상 어플라이언스 또는 SaaS 솔루션을 선택합니다. 다음 홉 리소스에서 관련된 다음 홉 리소스를 선택합니다.
프라이빗 트래픽 라우팅 정책을 구성하고 비 IANA RFC1918 접두사를 사용하는 분기 또는 가상 네트워크가 있는 경우 추가 접두사를 선택하고 표시되는 텍스트 상자에 비 IANA RFC1918 접두사 범위를 지정합니다. 완료를 선택합니다. 프라이빗 라우팅 정책으로 구성된 모든 Virtual Hub의 프라이빗 트래픽 접두사 입력란에 동일한 접두사를 추가하여 모든 허브에 올바른 경로가 보급되도록 합니다.
인터넷 트래픽 라우팅 정책을 구성하려면 Azure Firewall, 네트워크 가상 어플라이언스 또는 SaaS 솔루션을 선택합니다. 다음 홉 리소스에서 관련된 다음 홉 리소스를 선택합니다.
라우팅 의도 및 라우팅 정책 구성을 적용하려면 저장을 클릭합니다.
라우팅 정책을 구성하려는 모든 허브에 대해 반복합니다.
이제 테스트 트래픽을 보낼 준비가 되었습니다. 원하는 보안 구성에 따라 트래픽을 허용/거부하도록 Firewall 정책이 적절하게 구성되어 있는지 확인하세요.
BICEP 템플릿을 사용하여 라우팅 의도 구성
템플릿 및 단계에 대한 자세한 내용은 BICEP 템플릿을 참조하세요.
문제 해결
다음 섹션에서는 Virtual WAN Hub에서 라우팅 의도와 정책을 구성할 때 발생하는 문제를 해결하는 일반적인 방법을 설명합니다.
유효한 경로
참고 항목
Virtual WAN 라우팅 의도 다음 홉 리소스에 효과적인 경로를 적용하는 것은 프라이빗 라우팅 정책에 지정된 다음 홉 리소스에 대해서만 지원됩니다. 프라이빗 라우팅 정책과 인터넷 라우팅 정책을 모두 사용하는 경우 프라이빗 라우팅 정책에 지정된 다음 홉 리소스의 유효 경로에서 인터넷 라우팅 정책의 다음 홉 리소스의 Virtual WAN 프로그램의 유효 경로를 확인합니다. 인터넷 라우팅 정책만 사용하는 경우, defaultRouteTable에서 유효 경로를 확인하여 인터넷 라우팅 정책의 다음 홉 리소스에 프로그래밍된 경로를 확인합니다.
가상 허브에서 프라이빗 라우팅 정책을 구성하면 온-프레미스와 Virtual Network 간의 모든 트래픽이 가상 허브의 Azure Firewall, 네트워크 가상 어플라이언스 또는 SaaS 솔루션에서 검사됩니다.
따라서 defaultRouteTable의 유효 경로는 다음 홉 Azure Firewall 또는 네트워크 가상 어플라이언스와 함께 RFC1918 집계 접두사(10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12)를 표시합니다. 이는 Virtual Network와 분기 간의 모든 트래픽이 검사를 위해 허브의 Azure Firewall, NVA 또는 SaaS 솔루션으로 라우팅됨을 반영합니다.
Firewall에서 패킷을 검사하면 (그리고 Firewall 규칙 구성별로 패킷이 허용되면) Virtual WAN은 패킷을 최종 대상으로 전달합니다. Virtual WAN에서 검사된 패킷을 전달하는 데 사용하는 경로를 확인하려면, Firewall 또는 네트워크 가상 어플라이언스의 유효 경로 테이블을 확인하세요.
Firewall 유효 경로 테이블을 사용하면 잘못된 구성 또는 특정 분기 및 Virtual Network 관련 문제 같은 네트워크 문제를 좁히거나 격리할 수 있습니다.
구성 문제 해결
구성 문제를 해결할 때는 다음을 고려해야 합니다.
- 다음 홉 Virtual Network 연결이 있는 defaultRouteTable에 사용자 지정 경로 테이블이나 정적 경로가 없는지 확인합니다.
- 배포가 위의 요구 사항을 충족하지 않는 경우 라우팅 의도 구성 옵션이 Azure Portal에서 회색으로 표시됩니다.
- CLI, PowerShell 또는 REST를 사용하면 라우팅 의도 생성 작업이 실패하게 됩니다. 실패한 라우팅 의도를 삭제하고, 사용자 지정 경로 테이블과 정적 경로를 제거한 다음 다시 만듭니다.
- Azure Firewall Manager를 사용하는 경우에는 defaultRouteTable에 private_traffic, internet_traffic 또는 all_traffic이라는 기존 경로가 있는지 확인합니다. 경로 이름이 다르게 지정되면 라우팅 의도 구성 옵션(허브 간 사용 설정)이 회색으로 표시됩니다.
- 허브에서 라우팅 의도를 구성한 후에는, 허브에 대한 기존 연결 또는 새 연결에 대한 업데이트가 생성되었고 선택적 연결된 경로 테이블 필드와 전파된 경로 테이블 필드가 비어 있음으로 설정되어 있는지 확인합니다. 선택적 연결 및 전파를 비어 있음으로 설정하는 작업은 Azure Portal을 통해 수행되는 모든 작업에 대해 자동으로 수행됩니다.
데이터 경로 문제 해결
알려진 제한 사항 섹션을 이미 검토했다고 가정할 때, 데이터 경로 및 연결 문제를 해결하는 대표적인 방법은 다음과 같습니다.
- 유효 경로 관련 문제 해결:
- 프라이빗 라우팅 정책이 구성된 경우, 다음 홉 Firewall이 있는 경로가 RFC1918 집계(10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12)에 대한 defaultRouteTable의 유효 경로와 프라이빗 트래픽 텍스트 상자에 지정된 접두사에 표시됩니다. 모든 Virtual Network 및 온-프레미스 접두사가 defaultRouteTable의 정적 경로 내 서브넷인지 확인합니다. 온-프레미스 또는 Virtual Network가 defaultRouteTable의 유효 경로 내에서 서브넷이 아닌 주소 공간을 사용하는 경우, 프라이빗 트래픽 텍스트 상자에 접두사를 추가합니다.
- 인터넷 트래픽 라우팅 정책이 구성된 경우 defaultRouteTable의 유효 경로에 기본(0.0.0.0/0) 경로가 표시되어야 합니다.
- defaultRouteTable의 유효 경로에 올바른 접두사가 있는지 확인했다면, 네트워크 가상 어플라이언스 또는 Azure Firewall의 유효 경로를 확인합니다. Firewall의 유효 경로는 Virtual WAN이 선택한 경로를 표시하고 Firewall이 패킷을 전달할 수 있는 대상을 결정합니다. 누락되거나 상태가 올바르지 않은 접두사를 파악하면 데이터 경로 문제를 좁히고 올바른 VPN, ExpressRoute, NVA 또는 BGP 연결을 파악해 문제를 해결할 수 있습니다.
- 시나리오별 문제 해결:
- Virtual WAN에 비보안 허브(Azure Firewall이나 NVA가 없는 허브)가 있는 경우, 비보안 허브에 대한 연결이 라우팅 의도가 구성된 허브의 defaultRouteTable로 전파되는지 확인합니다. 전파가 defaultRouteTable로 설정되지 않은 경우, 보안 허브에 대한 연결은 비보안 허브로 패킷을 보낼 수 없습니다.
- 인터넷 라우팅 정책을 구성한 경우, 0.0.0.0/0 기본 경로를 학습해야 하는 모든 연결에 대해 '기본 경로 전파' 또는 '인터넷 보안 사용 설정' 설정이 'true'로 설정되어 있는지 확인합니다. 이 설정이 'false'로 설정된 연결은 인터넷 라우팅 정책이 구성된 경우에도 0.0.0.0/0 경로를 학습하지 않습니다.
- 가상 허브에 연결된 Virtual Network에 배포된 프라이빗 엔드포인트를 사용하는 경우 Virtual WAN 허브에 연결된 Virtual Network에 배포된 프라이빗 엔드포인트로 향하는 온-프레미스의 트래픽은 기본적으로 다음 홉 Azure Firewall, NVA 또는 SaaS에서 라우팅 의도를 무시합니다 . 하지만 그 결과 스포크 Virtual Network의 프라이빗 엔드포인트가 온-프레미스 트래픽을 Firewall로 전달함에 따라 비대칭 라우팅이 발생하게 됩니다(온-프레미스와 프라이빗 엔드포인트 간의 연결 손실로 이어질 수 있음). 라우팅 대칭을 보장하려면 프라이빗 엔드포인트가 배포된 서브넷에서 프라이빗 엔드포인트에 대한 경로 테이블 네트워크 정책을 사용하도록 설정합니다. 프라이빗 트래픽 텍스트 상자에 있는 프라이빗 엔드포인트 개인 IP 주소에 대응하는 /32 경로를 구성해도, 허브에서 프라이빗 라우팅 정책이 구성되어 있다면 트래픽 대칭이 보장되지 않습니다.
- 암호화된 ExpressRoute를 프라이빗 라우팅 정책과 함께 사용하는 경우, Firewall 디바이스에 Virtual WAN 사이트 간 VPN Gateway 프라이빗 IP 터널 엔드포인트와 온-프레미스 VPN 디바이스 간의 트래픽을 허용하도록 구성된 규칙이 있는지 확인합니다. ESP(암호화된 외부) 패킷은 Azure Firewall 로그에 로그해야 합니다. 라우팅 의도를 사용하여 암호화된 ExpressRoute에 대한 자세한 내용은 암호화된 ExpressRoute 설명서를 참조하세요.
- 스포크 가상 네트워크에서 사용자 정의 경로 테이블을 사용하는 경우 경로 테이블에서 "게이트웨이 경로 전파"가 "예"로 설정되어 있는지 확인합니다. Virtual WAN이 Virtual WAN에 연결된 스포크 Virtual Network에 배포된 워크로드에 경로를 보급하려면 "게이트웨이 경로 전파"를 사용하도록 설정해야 합니다. 사용자 정의 경로 테이블 설정에 대한 자세한 내용은 Virtual Network 사용자 정의 라우팅 설명서를 참조 하세요.
Azure Firewall 라우팅 문제 해결
- 라우팅 의도를 구성하기 전에 Azure Firewall의 프로비전 상태가 성공인지 확인합니다.
- 분기/Virtual Network에서 비 IANA RFC1918 접두사를 사용하는 경우 "프라이빗 접두사" 텍스트 상자에 해당 접두사를 지정했는지 확인합니다. 구성된 "프라이빗 접두사"는 라우팅 의도로 구성된 Virtual WAN의 다른 허브로 자동으로 전파되지 않습니다. 연결을 보장하려면 라우팅 의도가 있는 모든 단일 허브의 "프라이빗 접두사" 텍스트 상자에 해당 접두사를 추가해야 합니다.
- Firewall Manager에서 프라이빗 트래픽 접두사 텍스트 상자의 일부로 비 RFC1918 주소를 지정한 경우 비 RFC1918 프라이빗 트래픽에 대해 SNAT를 사용하지 않도록 Firewall에서 SNAT 정책을 구성해야 할 수 있습니다. 자세한 내용은 Azure Firewall SNAT 범위를 참조하세요.
- 네트워크 트래픽 문제를 해결하고 분석하는 데 도움이 되도록 Azure Firewall 로그를 구성하고 확인합니다. Azure Firewall에 대한 모니터링을 설정하는 방법에 대한 자세한 내용은 Azure Firewall 진단을 참조하세요. 다양한 유형의 Firewall 로그에 대한 개요는 Azure Firewall 로그 및 메트릭을 참조하세요.
- Azure Firewall에 대한 자세한 내용은 Azure Firewall 설명서를 검토하세요.
네트워크 가상 어플라이언스 문제 해결
- 라우팅 의도를 구성하기 전에 네트워크 가상 어플라이언스의 프로비전 상태가 성공인지 확인합니다.
- 온-프레미스 또는 Virtual Network에서 비 IANA RFC1918 접두사를 사용하는 경우, "프라이빗 접두사" 텍스트 상자에 해당 접두사를 지정했는지 확인합니다. 구성된 "프라이빗 접두사"는 라우팅 의도로 구성된 Virtual WAN의 다른 허브로 자동으로 전파되지 않습니다. 연결을 보장하려면 라우팅 의도가 있는 모든 단일 허브의 "프라이빗 접두사" 텍스트 상자에 해당 접두사를 추가해야 합니다.
- 프라이빗 트래픽 접두사 텍스트 상자의 일부로 비 RFC1918 주소를 지정한 경우, 특정 비 RFC1918 프라이빗 트래픽에 대해 SNAT를 사용하지 않도록 NVA에서 SNAT 정책을 구성해야 할 수 있습니다.
- NVA 방화벽 로그를 확인하여 방화벽 규칙에 의해 트래픽이 삭제되거나 거부되는지 확인합니다.
- 문제 해결에 대한 추가 지원 및 지침을 확인하고 싶다면 NVA 공급자에게 문의하세요.
서비스 제공 소프트웨어 문제 해결
- 라우팅 의도를 구성하기 전에 SaaS 솔루션의 프로비전 상태가 성공인지 확인합니다.
- 자세한 문제 해결 팁은 Virtual WAN 설명서의 문제 해결 섹션을 참조하거나 Palo Alto Networks Cloud NGFW 설명서를 참조하세요.
다음 단계
가상 허브 라우팅에 대한 자세한 내용은 가상 허브 라우팅 정보를 참조하세요. Virtual WAN에 대한 자세한 내용은 FAQ를 참조하세요.