Virtual WAN 허브 라우팅 의도 및 라우팅 정책을 구성하는 방법
가상 WAN 허브 라우팅 의도를 사용하면 Virtual WAN 허브 내에 배포된 Azure Firewall, 네트워크 가상 디바이스나 서비스 제공 소프트웨어(SaaS) 솔루션 같은 BITM(Bump-in-The-Wire) 보안 솔루션에 트래픽을 전송하는 간단하고 선언적인 라우팅 정책을 설정할 수 있습니다.
배경
라우팅 의도와 라우팅 정책을 사용하면 인터넷 한정 및 프라이빗(지점 및 사이트 간 VPN, 사이트 간 VPN, ExpressRoute, Virtual Network 및 네트워크 가상 어플라이언스) 트래픽을 가상 허브에 배포된 Azure Firewall, 차세대 방화벽 네트워크 가상 어플라이언스(NGFW-NVA) 또는 보안 서비스 제공 소프트웨어(SaaS) 솔루션으로 전달하도록 Virtual WAN 허브를 구성할 수 있습니다.
라우팅 정책에는 인터넷 트래픽 정책 및 프라이빗 트래픽 라우팅 정책의 두 가지 유형이 있습니다. 각 Virtual WAN 허브에는 각각 단일 다음 홉 리소스를 포함하는 최대 1개의 인터넷 트래픽 라우팅 정책과 1개의 프라이빗 트래픽 라우팅 정책이 있을 수 있습니다. 프라이빗 트래픽은 분기 및 Virtual Network 주소 접두사를 모두 포함하지만, 라우팅 정책은 두 항목을 라우팅 의도 개념에 속하는 단일 엔터티로 간주합니다.
인터넷 트래픽 라우팅 정책: 인터넷 트래픽 라우팅 정책을 Virtual WAN 허브에 대해 구성하는 경우 모든 분기(원격 사용자 VPN(지점 및 사이트 간 VPN), 사이트 간 VPN 및 ExpressRoute) 및 해당 Virtual WAN 허브에 대한 Virtual Network 연결을 통해 인터넷 바인딩된 트래픽을 라우팅 정책의 일부로 지정된 Azure Firewall, 타사 보안 공급자, 네트워크 가상 어플라이언스 또는 SaaS 솔루션으로 전달합니다.
즉, 인터넷 트래픽 라우팅 정책이 Virtual WAN 허브에 구성되면 Virtual WAN은 모든 스포크, 게이트웨이 및 네트워크 가상 어플라이언스(허브 또는 스포크에 배포)에 기본(0.0.0.0/0) 경로를 전파합니다.
프라이빗 트래픽 라우팅 정책: 프라이빗 트래픽 라우팅 정책이 Virtual WAN 허브에 대해 구성된 경우 허브 간 트래픽을 포함하여 모든 분기 트래픽 및 Virtual WAN 허브 내부 및 외부의 Virtual Network 트래픽이 다음 홉 Azure Firewall, 네트워크 가상 어플라이언스 또는 SaaS 솔루션 리소스로 전달됩니다.
즉, Virtual WAN 허브에 대해 프라이빗 트래픽 라우팅 정책이 구성되어 있는 경우 모든 분기 간, 분기 및 가상 네트워크 간, 가상 네트워크 및 분기 간, 허브 간 트래픽은 Azure Firewall이나 네트워크 Virtual WAN 허브에 배포된 네트워크 가상 어플라이언스 또는 SaaS 솔루션을 통해 전송됩니다.
사용 사례
다음 섹션에서는 라우팅 정책이 보안 Virtual WAN 허브에 적용되는 두 가지 일반적인 시나리오에 대해 설명합니다.
모든 Virtual WAN 허브가 보호됩니다(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 구성:
- N/A(허브가 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 퍼블릭에서 사용할 수 있습니다. 21Vianet 및 Azure Government에서 운영하는 Microsoft Azure는 현재 로드맵에 있습니다.
- 라우팅 의도는 모든 연결(Virtual Network, 사이트 간 VPN, 지점 및 사이트 간 VPN 및 ExpressRoute)에 대한 경로 테이블 연결 및 전파를 관리하여 라우팅을 간소화합니다. 따라서 사용자 지정 경로 테이블 및 사용자 지정 정책이 포함된 Virtual WAN은 라우팅 의도 구문과 함께 사용할 수 없습니다.
- 암호화된 ExpressRoute(ExpressRoute 회로를 통해 실행하는 사이트 간 VPN 터널)는 Azure Firewall이 VPN 터널 엔드포인트 간의 트래픽(사이트 간 VPN 게이트웨이 프라이빗 IP 및 온-프레미스 VPN 디바이스 프라이빗 IP)을 허용하도록 구성된 경우, 라우팅 의도가 구성된 허브에서 지원됩니다. 필요한 구성에 대한 자세한 내용은 라우팅 의도가 있는 암호화된 ExpressRoute를 참조하세요.
- 다음 연결 사용 사례는 라우팅 의도에서 지원되지 않습니다.
- Virtual Network 연결을 가리키는 defaultRouteTable의 정적 경로는 라우팅 의도와 함께 사용할 수 없습니다. 그러나 BGP 피어링 기능은 사용할 수 있습니다.
- 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 유형을 살펴볼 수 있습니다.
- 여러 ExpressRoute 회로를 Virtual WAN에 연결하고 허브에 배포된 보안 솔루션을 통해 이러한 회로 간에 트래픽을 전송하려는 라우팅 의도 사용자는 지원 사례를 열어 이 사용 사례를 사용하도록 설정할 수 있습니다. 자세한 내용은 ExpressRoute 회로에서 연결을 사용하도록 설정 항목을 참조하세요.
고려 사항
라우팅 의도가 없는 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 정보를 참조하세요.
필수 조건
라우팅 의도 및 정책을 사용하도록 설정하려면 가상 허브가 아래 필수 조건을 충족해야 합니다.
- 가상 허브를 이용해 배포된 사용자 지정 경로 테이블이 없습니다. 존재하는 경로 테이블은 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 회로에서 연결을 사용하도록 설정 항목을 참조하세요.
라우팅 의도를 사용한 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를 사용하여 프라이빗 라우팅 정책을 구성하면 허브에 배포된 다음 홉 보안 어플라이언스 통해 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 디바이스를 구성합니다.
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 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 설명서를 참조하세요.
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를 참조하세요.