TOPIC/Cloud

Azure Route Table 공부하기 (5)

H-Y-E-N 2024. 5. 10. 15:37

안녕하세요. HYEN입니다.

시나리오 세 번째 글이자 이번 Route Table 공부하기의 마지막 글입니다~~~🎉🎉🎉

물론 마지막 시나리오의 내용 중 추가적으로 다룰 부분은 새로운 글로 적을 예정이지만! 

드디어 마무리라니...😂 감회가 새롭습니다.

 

이전 글 : https://with-cloud.tistory.com/51

 

Azure Route Table 공부하기 (4)

안녕하세요. HYEN입니다. 시나리오 두 번째 글로 찾아왔습니다! 연휴와 개인 사정이 겹쳐 이전 글과 다소 시간 차가 있지만 양해 부탁드리며, 두 개의 시나리오에 대해 다뤄보았습니다. 이전 글

with-cloud.tistory.com


Contents

     

    3. 시나리오 

    3.5 Spoke VM → Spoke 대역의 PostgreSQL 

     시나리오 아키텍처 및 구성하고자 하는 트래픽 플로우는 다음과 같습니다. 

     

    현재 Spoke 가상 네트워크 내에서의 통신은 Azure Firewall을 거치지 않고 있습니다. 

     

    경로 테이블의 유효 경로를 확인해 보겠습니다. 

    Spoke 가상 머신이 배포된 서브넷의 유효 경로는 상기 스크린샷과 같습니다. 

    다음 홉이 가상 네트워크인 경로가 활성화되어 있습니다. 

    즉, Spoke 가상 네트워크 내에서는 Azure Firewall을 거치지 않고 가상 네트워크 내에서 각 서브넷으로 라우팅이 되게 되는 것이죠. 

     

    가상 머신의 [연결 문제 해결] 탭에서도 다음 홉 형식을 확인할 수 있습니다. 

    Spoke 가상 머신에서 VNet Integration된 Azure Database for PostgreSQL Flexible Server로 향하는 트래픽에 대한 다음 홉을 테스트해 보았습니다. 

    상기 스크린샷과 같이 사용자 지정 경로를 따르는 것이 아니라 default로 정의된 시스템 경로를 따르는 것을 알 수 있습니다. 

     

    그렇다면 Private Endpoint와 연결된 Azure Database for PostgreSQL Flexible Server는 어떨까요?

     

    경로 테이블의 유효 경로에는 하기와 같이 InterfaceEndpoint 즉 Private Endpoint를 다음 홉으로 하는 시스템 경로가 존재하는 것을 알 수 있습니다. 

    가상 머신의 [연결 문제 해결] 탭에서도 Private Endpoint의 Private IP를 목적지로 설정하여 다음 홉에 대한 진단을 실행하면 하기와 같이 트래픽이 다음 홉이 PrivateEndpoint인 시스템 경로를 따르는 것을 알 수 있습니다. 

     

    Hub와 통신할 때에는 Azure Firewall을 거치고 Spoke 내에서는 각 서브넷끼리 직접 통신할 수 있도록 구성이 잘 되어 있음을 알 수 있습니다.

     

    3.6 Spoke VM → Azure Firewall → Spoke 대역의 PostgreSQL

    그렇다면, Spoke 내에서의 통신도 Azure Firewall을 거쳐가게 할 수 있을까요?

     

    답은 YES입니다. 

     

    앞서 Azure의 경로 테이블은 Longest Prefix Match 알고리즘을 따른다고 했는데요. 

    현재 Spoke 내에서의 통신에 대한 경로는 다음과 같습니다. 

    이보다 더 대역이 작은 사용자 지정 경로를 지정하여 다음 홉 유형을 가상 어플라이언스로 지정해 준다면 Spoke 대역 내에서의 통신도 Azure Firewall을 거치게 될 것입니다. 

     

    먼저, Spoke 가상 머신에서 Azure Firewall을 거쳐, Private Endpoint와 연결된 Azure Database for PostgreSQL Flexible Server에 접근하도록 테스트해보겠습니다.

    시나리오 아키텍처 및 구성하고자 하는 트래픽 플로우는 다음과 같습니다. 

     

    이를 위해 Spoke 경로 테이블에 서브넷 단위의 사용자 지정 경로를 추가해 줍니다. 

     

    • [경로 테이블] > [설정] 블레이드 > [경로] 탭 > [+ 추가]

    위의 경로를 생성하면, 해당 경로 테이블과 연결된 서브넷들 중 대상 IP 주소로 가려고 하는 트래픽이 있을 경우 이 트래픽은 Azure Firewall로 보내지게 됩니다. 

    그렇게 되면 Azure Firewall과 연결된 방화벽 정책에 연결된 규칙에 기반하여 트래픽이 라우팅 되게 됩니다. 

     

    따라서 Azure Firewall로 보내진 트래픽이 목적지를 찾아갈 수 있도록 이번에는 방화벽 정책에 Network 규칙을 생성해 주겠습니다.

     

    • 먼저 기존 규칙 컬렉션 (Hub-Spoke 간 통신 관련)과 다른 새로운 규칙 컬렉션을 생성합니다. ([설정] 블레이드 > [규칙 컬렉션] 탭 > [+ Add] > [Rule Collection])

    설정이 완료되었으니 가상 머신의 [연결 문제 해결] 탭에서 연결 진단을 통해 다음 홉에 대해 확인해 보겠습니다.

    진단 결과 다음 홉 유형이 가상 어플라이언스(Azure Firewall)로 트래픽이 시스템 경로가 아닌 방금 전 지정해 준 사용자 지정 경로를 따라 흐르는 것을 알 수 있습니다. 

     

    Spoke 가상 머신에서도 PostgreSQL 서버에  접근해 보겠습니다. 

    잘 접근되는 것을 알 수 있습니다. 

     

    다음은 Spoke 가상 머신에서 Azure Firewall을 거쳐, VNet Integration 된 Azure Database for PostgreSQL Flexible Server에 접근하도록 테스트해보겠습니다.

    시나리오 아키텍처 및 구성하고자 하는 트래픽 플로우는 다음과 같습니다. 

     

    이를 위해 Spoke 경로 테이블에 서브넷 단위의 사용자 지정 경로를 추가해 줍니다. 

     

    • [경로 테이블] > [설정] 블레이드 > [경로] 탭 > [+ 추가]

     

    다음으로 Azure Firewall에 가상 머신 ↔ Azure Database for PostgreSQL Flexible Server (VNet Integration) 간 통신에 필요한 Network 규칙을 추가해 줍니다. 

     

    설정이 완료되었으니 가상 머신의 [연결 문제 해결] 탭에서 연결 진단을 통해 다음 홉에 대해 확인해 보겠습니다.

     

    진단 결과 다음 홉 유형이 가상 어플라이언스(Azure Firewall)로 트래픽이 시스템 경로가 아닌 방금 전 지정해 준 사용자 지정 경로를 따라 흐르는 것을 알 수 있습니다. 

     

    Spoke 가상 머신에서도 PostgreSQL 서버에 접근해 보겠습니다. 

    Private Endpoint와 연결된 PostgreSQL 서버와는 다르게 접근이 안 되는 것을 알 수 있습니다. 

     

    이 이유에 대해서는 다음 글에서 다루도록 하겠습니다! 

     


    긴 글 읽어주셔서 감사합니다! 

    728x90
    320x100
    SMALL