안녕하세요. HYEN입니다.
시나리오 두 번째 글로 찾아왔습니다!
연휴와 개인 사정이 겹쳐 이전 글과 다소 시간 차가 있지만 양해 부탁드리며, 두 개의 시나리오에 대해 다뤄보았습니다.
이전 글 : https://with-cloud.tistory.com/50
Contents
3. 시나리오
3.3 Hub VM → Azure Firewall → PostgreSQL (VNet Integration)
시나리오 아키텍처 및 구성하고자 하는 트래픽 플로우는 다음과 같습니다.
이를 위해 3.2 에서 수행했던 과정을 동일하게 진행합니다.
그 전에 Azure Database for PostgreSQL Flexible Server에 대한 Private DNS Zone에 Hub 대역의 가상 네트워크를 연결해 주어야 합니다.
- privatelink.postgres.database.azure.com이라는 이름의 Private DNS Zone을 찾아 [설정] 블레이드의 [가상 네트워크 링크] 탭을 클릭합니다. [+ 추가] 버튼을 클릭하여 가상 네트워크 링크를 진행합니다.
- 링크 이름과 연결할 가상 네트워크(Hub VNet)를 선택한 후 [확인] 버튼을 클릭하여 링크 생성을 마무리합니다.
그 다음, 각 대역의 사용자 지정 경로에 서브넷을 연결하고 경로를 추가합니다.
[Hub 대역의 경로 테이블]
- Hub 가상 머신이 배포되어 있는 서브넷은 이미 Hub 대역의 경로 테이블과 연결되어 있기 때문에 서브넷 연결 과정은 진행하지 않아도 됩니다.
- 경로 역시 이미 0.0.0.0/0, 즉 모든 트래픽에 대해 Azure Firewall로 라우팅되도록 구성되어 있기 때문에 해당 과정은 진행하지 않아도 됩니다.
[Spoke 대역의 경로 테이블]
- [설정] 블레이드 > [서브넷] 탭 > [+ 연결]
- Spoke 대역에서 Hub 가상 머신으로 가기 위한 경로는 이미 구성되어 있기 때문에 경로는 추가로 생성하지 않아도 됩니다.
경로를 추가한 후 방화벽 정책으로 이동하여 Network 규칙을 생성합니다.
- [설정] 블레이드 > [규칙 컬렉션] 탭에서 Network 규칙 컬렉션을 선택합니다. (규칙을 한번에 추가하기 위함입니다.)
- Hub ↔ Postgre01(VNet Integration) 연결을 위해 Network 규칙을 생성해 줍니다.
From-Hub-to-Postgre01 규칙만 추가하면 Hub 가상 머신에서 Azure Firewall을 거쳐 Postgre01까지 가는 트래픽만 허용됩니다. 따라서, From-Postgre01-to-Hub 규칙을 추가해서 Postgre01에서 Azure Firewall을 거쳐 Hub 가상 머신으로 가는 트래픽이 허용될 수 있도록 해야 합니다.
규칙 생성이 완료된 후, Hub 가상 머신에서 Postgre01에 접근해 보겠습니다.
접근하기 위한 명령어는 Azure Database for PostgreSQL Flexible Server의 [설정] 블레이드 > [연결] 탭의 "브라우저에서 또는 로컬에서 연결" 섹션을 확인하면 됩니다.
(아키텍처 상에는 VNet Integration된 Azure Database for PostgreSQL Flexible Server 명이 postgre-hyein-01로 되어 있으나 실제 리소스 생성 명은 postgre-hyein-02인 점 양해 부탁드립니다. 😓)
명령어를 복사하여 Hub 가상 머신에서 실행합니다.
접근이 잘 되는 것을 확인할 수 있습니다.
가상 머신의 [도움말] > [연결 문제 해결] 탭에서 다음 홉을 확인하여 트래픽이 예상한 대로 흐르는지 확인해 보도록 하겠습니다.
이를 확인하기 위해서는 먼저 IP 주소 확인이 필요한데요.
privatelink.postgres.database.azure.com이라는 이름의 Private DNS Zone으로 이동하여 레코드를 확인합니다.
해당 IP 주소를 복사해 둡니다.
다시 [연결 문제 해결] 탭으로 이동하여 대상 주소 섹션 중 "URI, FQDN 또는 IP 주소" 칸에 복사해 둔 IP 주소를 입력합니다.
진단 테스트 결과 현재 다음 홉이 VirtualNetworkPeering으로 지정되어 있는 것을 확인할 수 있습니다.
이는 테스트 시나리오대로 트래픽이 흐르고 있지 않은 것을 의미합니다.
무엇이 문제일까요? 😓
답은 경로에 있습니다.
Azure는 Longest Prefix Match 알고리즘을 따르기 때문에 접두사가 더 긴, 즉 주소 대역이 더 작은 경로를 따르게 됩니다.
현재 udr-hub-hyein이라는 경로 테이블의 유효 경로 테이블은 하기와 같습니다.
0.0.0.0/0 즉 모든 트래픽에 대한 다음 홉이 Azure Firewall로 지정되어 있지만 그 보다 더 작은 범위인 10.100.0.0/24 즉, Spoke 대역의 가상 네트워크에 대한 다음 홉이 VNet 피어링으로 지정되어 있기 때문에 트래픽은 Azure Firewall이 아니라 VNet Peering이 다음 홉인 경로를 따라가고 있음을 알 수 있습니다.
따라서, 경로 테이블에 Spoke 가상 네트워크 대역보다 작거나 동일한 크기의 대역에 대한 경로를 명시해 주어야 합니다.
- [경로 테이블] > [설정] 블레이드 > [경로] 탭에서 경로를 추가해 줍니다.
경로를 추가한 후 다시 연결 진단을 실행하면 이번에는 트래픽이 하기와 같이 다음 홉 유형이 Azure Firewall인 경로를 따라 흐르는 것을 확인할 수 있습니다.
3.4 Hub VM → Azure Firewall → PostgreSQL (Private Endpoint)
시나리오 아키텍처 및 구성하고자 하는 트래픽 플로우는 다음과 같습니다.
경로 테이블을 구성하기에 앞서 먼저 서브넷의 "프라이빗 엔드포인트에 대한 네트워크 정책"을 활성화 시켜야 합니다.
이 정책은 Private Endpoint에 대해 사용자 정의 경로 및 네트워크 보안 그룹과 같은 네트워크 정책을 사용하고자 할 경우 활성화 시켜야 하는 정책입니다.
단, 해당 설정은 서브넷의 Private Endpoint에만 적용되며 서브넷의 모든 Private Endpoint에 영향을 줍니다.
[가상 네트워크] > [설정] 블레이드 > [서브넷] 탭에서 해당 정책을 활성화할 서브넷을 선택합니다.
그 후, 가장 하단에 있는 프라이빗 엔드포인트에 대한 네트워크 정책 탭에서 [경로 테이블]을 선택합니다.
[Hub 대역의 경로 테이블]
- Hub 가상 머신이 배포되어 있는 서브넷은 이미 Hub 대역의 경로 테이블과 연결되어 있기 때문에 서브넷 연결 과정은 진행하지 않아도 됩니다.
- 경로 역시 이미 0.0.0.0/0, 즉 모든 트래픽에 대해 Azure Firewall로 라우팅되도록 구성되어 있기 때문에 해당 과정은 진행하지 않아도 됩니다.
[Spoke 대역의 경로 테이블]
- [설정] 블레이드 > [서브넷] 탭 > [+ 연결]
- Spoke 대역에서 Hub 가상 머신으로 가기 위한 경로는 이미 구성되어 있기 때문에 경로는 추가로 생성하지 않아도 됩니다.
경로를 추가한 후 방화벽 정책으로 이동하여 Network 규칙을 생성합니다.
- [설정] 블레이드 > [규칙 컬렉션] 탭에서 Network 규칙 컬렉션을 선택합니다. (규칙을 한번에 추가하기 위함입니다.)
From-Hub-to-Postgre02 규칙의 대상에는 Postgre02와 연결된 Private Endpoint가 배포되어 있는 서브넷의 대역을 입력해 주면 됩니다.
3.3 과정과 동일하게 Postgre02에 접근해 보겠습니다.
접근이 잘 되는 것을 확인할 수 있습니다.
다음으로 가상 머신 쪽에서 연결 진단을 실행해 보겠습니다.
다음 홉이 Azure Firewall인 경로로 트래픽이 잘 흐르는 것을 확인할 수 있습니다.
이렇게 Hub 가상 머신에서 Spoke 대역으로 접근하는 부분에 대한 테스트를 마무리하였습니다.
다음 글에서는 Spoke 대역 간의 통신에 대해 다뤄보도록 하겠습니다. 😽
'TOPIC > Cloud' 카테고리의 다른 글
Azure Route Table (Private Endpoint VS VNet Integration) (0) | 2024.05.13 |
---|---|
Azure Route Table 공부하기 (5) (0) | 2024.05.10 |
Azure Route Table 공부하기 (3) (0) | 2024.05.02 |
Azure Route Table 공부하기 (2) (0) | 2024.04.30 |
프라이빗 엔드포인트 VS VNET 통합 (프라이빗 액세스) (0) | 2024.04.30 |