IBM Cloud Docs
VPC Transit Hub and Spoke 아키텍처를 통한 커뮤니케이션 중앙 집중화 - 2부

VPC Transit Hub and Spoke 아키텍처를 통한 커뮤니케이션 중앙 집중화 - 2부

이 튜토리얼에서는 비용이 발생할 수 있습니다. Cost Estimator를 사용하여 예상 사용량을 기반으로 비용 추정값을 생성하십시오.

VPC (Virtual Private Cloud) 는 IBM Cloud에서 네트워크 격리 및 보안을 제공합니다. VPC는 기업 부서(마케팅, 개발, 회계 등)를 캡슐화하는 빌딩 블록이거나 DevSecOps 팀이 소유한 마이크로서비스의 집합일 수 있습니다. VPC는 온프레미스 엔터프라이즈 및 서로 연결될 수 있습니다. 이로 인해 중앙 집중식 방화벽 게이트웨이 어플라이언스를 통해 트래픽을 라우팅해야 할 필요가 있을 수 있습니다. 이 학습서는 이 상위 레벨 보기에 표시된 허브 및 스포크 아키텍처의 구현을 안내합니다.

*
아키텍처 다이어그램 *

이는 두 파트로 구성된 학습서 중 두 번째 파트입니다. 이 파트에서는 전송 허브 방화벽 라우터를 통해 VPC간의 모든 트래픽을 라우팅하는 데 중점을 둡니다. 네트워크 로드 밸런서를 사용하는 확장 가능한 방화벽 라우터에 대해 설명하고 구현합니다. 사설 DNS는 VPE (Virtual Private Endpoint) 게이트웨이를 사용하는 마이크로서비스 ID및 IBM Cloud 서비스 인스턴스 ID 모두에 사용됩니다.

이 학습서는 독립형이므로 파트 1 의 단계를 실행할 필요가 없습니다. IBM Cloud에서 VPC, 네트워크 IP 레이아웃 및 계획에 익숙하지 않은 경우, Transit Gateway, IBM Cloud® Direct Link 또는 비대칭 라우팅은 파트 1을 통한 읽기를 고려합니다.

허브 및 스포크 모델은 다양한 시나리오를 지원합니다.

  • 허브는 스포크 및 엔터프라이즈에서 사용되는 공유 마이크로 서비스의 저장소가 될 수 있습니다.
  • 허브는 엔터프라이즈와 클라우드 간의 트래픽 방화벽 라우터 및 라우팅의 중심 지점이 될 수 있습니다.
  • 허브는 트래픽-스포크 (spoke) <-> 스포크 (spoke), 스포크 (spoke) <-> 전송 또는 스포크 (spoke) <-> 엔터프라이즈의 전부 또는 일부를 모니터할 수 있습니다.
  • 허브는 스포크에서 공유하는 VPN 자원을 보유할 수 있습니다.
  • 허브는 VPC 보안 그룹 및 서브넷 액세스 제어 목록으로 제어되고 스포크 및 엔터프라이즈에서 공유되는 VPE(Virtual Private Endpoint)게이트웨이 를 통해 액세스되는 공유 클라우드 리소스 (예: 데이터베이스) 의 저장소가 될 수 있습니다.

연결을 여러 증분식 계층으로 나누는 동반 GitHub 저장소 가 있습니다. 튜토리얼에서는 얇은 레이어를 사용하여 바이트 크기 인증 확인 및 솔루션을 도입할 수 있습니다.

다음을 탐색합니다.

  • VPC 송신 및 수신 라우팅.
  • 가상 네트워크 기능 을 네트워크 로드 밸런서와 결합하여 고가용성 및 확장성을 지원합니다.
  • VPE 게이트웨이.
  • DNS 분석.

계층화된 아키텍처는 자원을 소개하고 연결성을 설명합니다. 각 계층은 추가 연결 및 자원을 추가합니다. 계층은 Terraform에서 구현됩니다. Terraform 변수를 변경하여 구역 수와 같은 매개변수를 변경할 수 있습니다. 계층화된 접근 방식을 사용하면 학습서에서 작은 문제점을 소개하고 완전한 아키텍처의 컨텍스트에서 솔루션을 시연할 수 있습니다.

목표

  • 모든 VPC대 VPC 트래픽을 관리하기 위한 VPC 기반 허브 및 스포크 모델의 개념을 이해합니다.
  • VPC 유입 및 유출 라우팅을 이해합니다.
  • 비대칭 라우팅 문제를 식별하고 선택적으로 해결합니다.
  • 고가용성의 확장 가능한 방화벽 라우터에 대한 네트워크 로드 밸런서의 사용을 이해합니다.
  • DNS 서비스 라우팅 및 전달 규칙을 활용하여 구조적으로 건전한 이름 해석 시스템을 빌드합니다.

시작하기 전에

이 튜토리얼에는 다음 항목이 필요합니다.

  • terraform: 인프라를 코드로 사용하여 리소스를 프로비저닝함
  • python 를 사용하여 선택적으로 pytest 명령을 실행하십시오.
  • 방화벽 라우터를 구현하려면 IP 스푸핑 검사를 사용으로 설정 해야 합니다.

전제조건 환경을 쉽게 작성하기 위한 Dockerfile을 포함한 몇 가지 옵션은 전제조건 을 참조하십시오.

또한 다음을 확인하십시오.

파트 1의 요약

이 튜토리얼의 파트 1 에서는 전송 및 스포크 VPC의 주소 공간을 신중하게 계획했습니다. 구역 기반 아키텍처가 아래에 표시되어 있습니다.

구역
구역

이 다이어그램은 트래픽 플로우를 표시합니다. 엔터프라이즈 <-> 스포크만 방화벽을 통과합니다.

트래픽 플로우
트래픽 플로우

이는 Direct Link, Transit Gateway 및 VPC 라우팅을 사용하여 수행되었습니다. 모든 구역은 비슷하게 구성되며 아래 다이어그램은 구역 1의 세부사항을 표시합니다.

VPC 레이아웃
VPC 레이아웃

CIDR 10.1.0.0/16 은 전송 및 스포크를 포함하며 Direct Link 를 통해 엔터프라이즈에 광고된 라우트로 전달됩니다. 마찬가지로 CIDR 192.168.0.0/24 는 엔터프라이즈를 포함하며 Transit Gateway 를 통해 광고된 라우트로 스포크에 전달됩니다.

스포크의 송신 라우트는 방화벽 라우터로 트래픽을 라우트합니다. 전송 라우트 엔터프라이즈의 Ingress 라우트 <-> 는 방화벽 라우터를 통해 트래픽을 스포크합니다.

방화벽 라우터를 통해 모든 내부 VPC 트래픽을 라우팅하는 초기 VPC 리소스 프로비저닝

엔터프라이즈는 종종 전송 VPC를 사용하여 방화벽 라우터로 트래픽을 모니터합니다. 부분적으로 하나의 엔터프라이즈 <-> 스포크 트래픽만 전송 방화벽 라우터를 통해 플로우되었습니다. 이 절에서는 방화벽 라우터를 통해 모든 VPC를 VPC 트래픽으로 라우팅하는 방법에 대해 설명합니다.

이 다이어그램은 이 단계에서 구현된 트래픽 플로우를 보여줍니다.

트래픽 플로우
트래픽 플로우

VPC간의 모든 트래픽은 방화벽 라우터를 통해 플로우됩니다.

  • 엔터프라이즈 <-> 스포크.
  • 엔터프라이즈 <-> 전송.
  • 전송 <-> 스포크.
  • spoke <-> 다른 VPC에서 스포크합니다.

VPC내의 트래픽은 방화벽을 통과하지 않습니다.

파트 1부터 계속하는 경우 terraform.tfvars: all_firewall = true 의 구성을 특별히 기록해 두십시오.

계층 적용

  1. 함께 제공되는 GitHub Repository 에는 아키텍처를 구현하기 위한 소스 파일이 있습니다. 데스크탑 쉘에서 저장소를 복제하십시오.

    git clone https://github.com/IBM-Cloud/vpc-transit
    cd vpc-transit
    
  2. config_tf 디렉토리에는 구성해야 하는 구성 변수가 포함되어 있습니다.

    cp config_tf/template.terraform.tfvars config_tf/terraform.tfvars
    
  3. config_tf/terraform.tfvars 를 편집하십시오.

    • 필요한 사항을 변경하십시오.
    • all_firwewall = true 값을 변경하십시오.
  4. 아직 가지고 있지 않다면, 플랫폼 API 키 를 구해서 Terraform에서 사용할 수 있도록 API 키를 내보내십시오

    export IBMCLOUD_API_KEY=YourAPIKEy
    
  5. 각 계층이 올바른 순서로 설치되고 이 학습서의 일부 단계에서 여러 계층을 설치하는 것이 중요하므로 쉘 명령 ./apply.sh 가 제공됩니다. 다음은 도움말을 표시합니다.

    ./apply.sh
    
  6. ./apply.sh : : 를 실행하여 구성된 모든 계층을 적용할 수 있습니다. 콜론은 첫 번째 (또는 config_tf) 및 마지막 (vpe_dns_forwarding_rules_tf) 의 약어입니다. -p 는 계층을 인쇄합니다.

    ./apply.sh -p : :
    
  7. 파트 1및 위에서 설명한 모든 계층을 적용하십시오 (파트 1에서 계속하는 경우에도 이 명령을 사용하여 구성 변경 all_firewall = true 으로 초기 계층을 다시 적용하십시오).

    ./apply.sh : spokes_egress_tf
    

부분적으로 진행 중인 경우 방화벽 라우터를 통한 라우팅을 방지하기 위해 일부 추가 Ingress 라우트가 전송 Ingress 라우트 테이블에 추가되었습니다. 이 단계에서는 구역에 대한 모든 수신 트래픽이 동일한 구역의 방화벽 라우터로 라우팅되도록 이러한 항목이 제거되었으며 전송 유입 라우트 테이블에는 이러한 항목만 있습니다. 다음 홉 주소는 다를 수 있지만 방화벽 라우터 인스턴스의 IP 주소가 됩니다.

구역 대상 다음 홉
Dallas10.1.0.0/1610.1.15.196
Dallas10.2.0.0/1610.2.15.196
Dallas10.3.0.0/1610.3.15.196

이를 관찰하려면 다음을 수행하

  1. IBM Cloud에서 VPC 를 여십시오.
  2. 전송 VPC 를 선택하고 주소 접두부가 표시되는지 확인하십시오.
  3. 경로 테이블 관리를 클릭 합니다
  4. Tgw-Ingress Transit Gateway Ingress 라우트 테이블을 클릭하십시오.

방화벽 라우터로 스포크 및 전송 라우트

스포크에서 시작되는 모든 클라우드 트래픽은 스포크의 기본 이그레스 라우팅 테이블(Dallas/us-south의 경우 표시됨)에 있는 이 경로를 통해 원본 인스턴스와 동일한 영역의 트랜짓 VPC 방화벽 라우터를 통해 라우팅이 수행됩니다:

구역 대상 다음 홉
Dallas10.0.0.0/810.1.15.196
Dallas10.0.0.0/810.2.15.196
Dallas10.0.0.0/810.3.15.196

마찬가지로 전송 VPC에서는 원래 인스턴스와 동일한 구역의 방화벽 라우터를 통해 모든 엔터프라이즈 및 클라우드 트래픽을 라우팅합니다. 예를 들어, 10.2.0.4 (스포크 0, 구역 2) 와 연결을 시도하는 대중교통 테스트 인스턴스 10.1.15.4 (대중교통 구역 1) 는 구역 1: 10.1.15.196의 방화벽 라우터를 통해 전송됩니다.

트랜짓의 기본 송신 라우팅 테이블에 있는 경로(달라스/미국-남쪽에 표시됨):

구역 대상 다음 홉
Dallas10.0.0.0/810.1.15.196
Dallas10.0.0.0/810.2.15.196
Dallas10.0.0.0/810.3.15.196
Dallas192.168.0.0/1610.1.15.196
Dallas192.168.0.0/1610.2.15.196
Dallas192.168.0.0/1610.3.15.196

방화벽 라우터로 Intra VPC 트래픽을 라우트하지 않음

이 예제에서 Intra-VPC 트래픽은 방화벽 라우터를 통과하지 않습니다. 예를 들어, 스포크 0의 자원은 스포크 0의 다른 자원에 직접 연결할 수 있습니다. 이를 수행하기 위해 보다 구체적인 라우트를 추가하여 내부 트래픽을 위임할 수 있습니다. 예를 들어, CIDR 범위가 10.1.0.0/24, 10.2.0.0/24, 10.3.0.0/24 인 스포크 0에서는 내부 라우트를 위임할 수 있습니다.

스포크 0의 기본 송신 라우팅 테이블에 있는 경로(댈러스/미국-남쪽에 표시됨):

구역 대상 다음 홉
Dallas 1 10.1.0.0/24 delegate
Dallas 1 10.2.0.0/24 delegate
Dallas 1 10.3.0.0/24 delegate
Dallas 2 10.1.0.0/24 delegate
Dallas 2 10.2.0.0/24 delegate
Dallas 2 10.3.0.0/24 delegate
Dallas 3 10.1.0.0/24 delegate
Dallas 3 10.2.0.0/24 delegate
Dallas 3 10.3.0.0/24 delegate

유사한 경로가 대중교통 및 기타 스포크에 추가됩니다.

방화벽 서브넷

방화벽 라우터 자체는 어떻습니까? 이는 이전에 언급되지 않았지만 이 변경사항을 예상하여 전송 VPC에서 작성된 egress_delegate 라우터가 모든 대상에 대한 기본값으로 라우팅을 위임합니다. 이는 방화벽 라우터 서브넷과만 연관되므로 방화벽 라우터는 다른 서브넷에서 사용되는 기본 송신 라우팅 테이블에 대한 변경사항의 영향을 받지 않습니다. 자세한 정보는 전송 VPC에 대한 라우팅 테이블을 확인하십시오. IBM Cloud 콘솔에서 VPC 를 방문하십시오. 전송 VPC를 선택한 후 라우팅 테이블 관리를 클릭하고 egress-delegate 라우팅 테이블을 클릭하고 서브넷 탭을 클릭한 후 방화벽 라우터에 사용되는 -fw 서브넷을 확인하십시오.

추가 방화벽 적용 및 테스트

  1. 계층을 적용하십시오.

    ./apply.sh all_firewall_tf
    
  2. 테스트 스위트를 실행하십시오.

    예상 결과는 다음과 같습니다. 교차 구역 전송 <-> 스포크 및 스포크 <-> 스포크는 FAILED 가 됩니다.

    pytest -m "curl and lz1 and (rz1 or rz2)"
    

교차 구역 라우팅 수정

앞에서 언급한 대로 시스템이 구역 간 장애에서 복원성을 갖도록 하려면 구역 간 트래픽을 제거하는 것이 가장 좋습니다. 교차 구역 지원이 필요한 경우 추가 유출 라우트를 추가할 수 있습니다. 스포크 0대 스포크 1트래픽의 문제점은 다음 다이어그램에 표시되어 있습니다.

교차 구역 라우팅 수정
교차 구역 라우팅 수정

녹색 경로는 스포크 1구역 1 10.1.1.4에 대한 발신인 스포크 0구역 2 10.2.0.4 라우팅의 예입니다. 일치하는 송신 라우트는 다음과 같습니다.

구역 대상 다음 홉
Dallas10.0.0.0/810.2.15.196

다이어그램의 중간 영역인 영역 2에서 방화벽 라우터를 왼쪽에서 오른쪽으로 이동하면 선택됩니다. 리턴 경로에서 구역 1이 선택됩니다.

이를 수정하려면 더 낮은 구역 번호 대상이 지정될 때 더 높은 구역이 더 낮은 구역 번호 방화벽으로 라우팅되도록 강제 실행하기 위해 몇 개의 더 많은 특정 라우트를 추가해야 합니다. 동일하거나 더 높은 번호의 구역을 참조할 때 동일한 구역의 방화벽으로 계속 라우트됩니다.

교차 구역 라우팅 사용
교차 구역 라우팅 사용

각 스포크의 기본 송신 라우팅 테이블의 경로(댈러스/미국-남쪽에 표시됨):

구역 대상 다음 홉
Dallas10.1.0.0/1610.1.15.196
Dallas10.1.0.0/1610.1.15.196
Dallas10.2.0.0/1610.2.15.196

또한 이러한 라우트는 유사한 전송 < -- > 스포크 교차 구역 비대칭 라우팅 문제점을 정정합니다. 대중교통 작업자 10.1.15.4- > 스포크 작업자 10.2.0.4를 고려하십시오. 구역 1의 대중교통 작업자로부터의 트래픽은 구역 1 (동일한 구역) 에서 방화벽 라우터를 선택합니다. 영역 2 (동일한 영역) 의 방화벽 라우터 대신 리턴 트립에서 영역 1의 방화벽 라우터가 사용됩니다.

  1. all_firewall_asym 계층을 적용하십시오.

    ./apply.sh all_firewall_asym_tf
    
  2. 테스트 스위트를 실행하십시오.

    예상 결과는 다음과 같습니다: 모든 테스트 합격, 병렬로 실행 (-n 10):

    pytest -n 10 -m curl
    

이제 VPC간의 모든 트래픽은 방화벽 라우터를 통해 라우팅됩니다.

고성능 고가용성 (HA) 방화벽-라우터

방화벽 라우터가 성능 병목 현상 또는 단일 장애 지점이 되지 않도록 하기 위해 VPC 네트워크 로드 밸런서를 추가하여 트래픽을 구역 방화벽 라우터에 분배하여 고가용성, HA, 방화벽 라우터를 작성할 수 있습니다. 방화벽 라우터 문서를 확인하여 이 아키텍처를 지원하는지 확인하십시오.

고가용성 방화벽
고가용성 방화벽

이 다이어그램은 두 개의 방화벽 라우터 앞에 라우트 모드 로 구성된 NLB (Network Load Balancer) 가 있는 단일 구역을 표시합니다. 이 구성을 보려면 구성을 변경하고 다시 적용해야 합니다.

  1. config_tf/terraform.tfvars: 에서 다음 두 변수를 변경하십시오.

    firewall_nlb                 = true
    number_of_firewalls_per_zone = 2
    

    이 변경으로 인해 방화벽 라우터의 IP 주소가 이전에 사용된 방화벽 라우터 인스턴스에서 NLB의 IP 주소로 변경됩니다. IP 주소 변경은 전송 및 스포크 VPC에서 다수의 VPC 라우트 테이블 라우트에 적용되어야 합니다. 이전에 적용된 모든 계층을 적용하는 것이 가장 좋습니다.

  2. all_firewall_asym_tf 계층을 통해 모든 계층을 적용하십시오.

    ./apply.sh : all_firewall_asym_tf
    

작성된 변경사항을 관찰하십시오.

  1. VPC용 로드 밸런서 를 여십시오.
  2. 접미사가 fw-z1-s3 영역 1(Dallas 1/us-south-1)에서 로드 밸런서를 선택합니다.
  3. 사설 IP 를 기록해 두십시오.

사설 IP를 전송 VPC 유입 라우트 테이블의 사설 IP와 비교하십시오.

  1. 가상 프라이빗 클라우드 를 여십시오.
  2. 대중교통 VPC를 선택하십시오.
  3. 라우팅 테이블 관리를 클릭하십시오.
  4. tgw-ingress 라우팅 테이블을 클릭하십시오. 다음 홉 IP 주소가 NLB 사설 IP 중 하나와 일치하는지 확인하십시오.

복원성 확인:

  1. 스포크 0구역 1테스트를 실행하십시오.
    pytest -k r-spoke0-z1 -m curl
    
  2. VPC용 가상 서버 인스턴스 를 여십시오.
  3. 인바운드 포트 80을 허용하지 않는 보안 그룹을 지정하여 0 방화벽 인스턴스에 대한 트래픽을 중지하십시오. 접미어가 fw-z1-s3-0 인 인스턴스를 찾고 세부사항 보기를 여십시오.
    1. 아래로 스크롤하여 네트워크 인터페이스 옆에 있는 연필 편집을 누르십시오.
    2. x-fw-inall-outall 선택 취소
    3. x-fw-in22-outall 을 확인하십시오.
    4. 저장을 클릭하십시오.
  4. Pytest를 다시 실행하십시오. 실패를 표시합니다. NLB가 응답하지 않는 인스턴스로의 트래픽 라우팅을 중지하는 데 몇 분이 소요되며, 이 시점에서 모든 테스트가 패스됩니다. 모든 테스트가 통과할 때까지 계속 대기하고 pytest 를 실행하십시오.

NLB 방화벽이 더 이상 필요하지 않습니다. NLB 방화벽을 제거하십시오.

  1. config_tf/terraform.tfvars: 에서 다음 두 변수를 변경하십시오.

    firewall_nlb                 = false
    number_of_firewalls_per_zone = 1
    
  2. all_firewall_asym_tf 계층을 통해 모든 계층을 적용하십시오.

    ./apply.sh : all_firewall_asym_tf
    

라우팅 모드에서 구성된 NLB에 대한 참고

NLB 라우트 모드는 라우트 테이블 항목을 다시 씁니다. 항상 장애 복구 중에 라우트 테이블에 활성 NLB 어플라이언스 IP 주소를 유지합니다. 그러나 이는 NLB를 포함하는 전송 VPC의 라우트에 대해서만 수행됩니다. 스포크에 NLB 어플라이언스 IP중 하나로 초기화된 송신 라우트가 있습니다. NLB 어플라이언스 장애 복구에서 스포크 다음 홉이 업데이트되지 않습니다.

활성 어플라이언스를 반영하기 위해 NLB에 의해 재작성되는 전송 VPC에서 Ingress 라우트를 유지보수해야 합니다. 스포크 유출 라우트는 전송 VPC의 올바른 구역으로 패킷을 전달합니다. 전송 VPC 구역 내의 라우팅은 활성 어플라이언스를 포함할 일치하는 Ingress 규칙을 찾습니다.

다음은 앞에서 설명한 전송 VPC Ingress 라우트 테이블입니다. 다음 홉은 활성 NLB 어플라이언스를 사용하여 최신 상태로 유지됩니다. Dallas 3에는 활성 어플라이언스를 반영하기 위해 NLB 경로 모드 서비스에 의해 변경된 내용이 있습니다.

구역 대상 다음 홉
Dallas10.0.0.0/810.1.15.196
Dallas10.0.0.0/810.2.15.196
Dallas10.0.0.0/810.3.15.197

NLB를 사용하려면 NLB가 VPC에 쓸 수 있도록 하는 IAM 권한을 작성해야 합니다. 이 권한은 apply.sh 스크립트에 의해 작성되었습니다. 스크립트가 수행한 구성에 대한 자세한 정보는 라우팅 모드를 사용하여 네트워크 로드 밸런서 작성 을 참조하십시오.

라우트 모드 NLB풀은 널로 설정된 세션 지속성 유형 으로 구성되어야 합니다.

DNS

IBM Cloud DNS Services 서비스는 이름을 IP 주소로 변환하는 데 사용됩니다. 이 예제에서 DNS 서비스는 클라우드에서 작성됩니다. DNS 구역 cloud.example.com 가 작성되고 전송 VPC가 허용된 네트워크로 추가됩니다. 클라우드 인스턴스에 대한 DNS 레코드가 cloud.example.com에 추가됩니다. 예를 들어, 전체 이름이 spoke0-z1-worker인 구역 1의 스포크 0작업자에 대해 A 레코드가 작성됩니다.cloud.example.com.

VPE 게이트웨이의 DNS 공유에 대한 정보 를 검토하십시오. 전송 VPC는 DNS 허브로 사용됩니다. 각 스포크 VPC는 전송 VPC 허브에 대한 DNS 분석 바인딩으로 구성됩니다. 이렇게 하면 DNS 서버에 대한 스포크 VPC DHCP 설정이 전송 VPC 사용자 정의 분석기가 되도록 구성됩니다.

DNS 레이아웃
DNS 레이아웃

DNS 자원

dns_tf 계층을 적용하여 전송 VPC및 스포크 VPC의 각 테스트 인스턴스에 대한 클라우드 DNS 구역 및 A 레코드를 추가하십시오. 엔터프라이즈 시뮬레이션을 위한 DNS 인스턴스도 작성됩니다.

./apply.sh dns_tf

작성된 DNS 서비스를 검사하십시오.

  1. IBM Cloud 콘솔에서 리소스 목록 을 여십시오.
  2. 네트워킹 섹션을 펼치고 DNS Services 를 확인하십시오.
  3. transit 라는 접미어가 있는 인스턴스를 찾아 클릭하여 여십시오.
  4. DNS 구역 cloud.example.com 을 클릭하십시오. 전송 및 스포크의 각 테스트 인스턴스와 연관된 A 레코드에 유의하십시오.
  5. 왼쪽에 있는 사용자 정의 분석기 탭을 클릭하고 분석기가 각 구역에 있는지 확인하십시오.
  6. 전달 규칙 탭을 클릭하고 전달 규칙을 확인하십시오. enterprise.example.com 는 온프레미스 분석기로 전달됩니다.

전송 및 스포크 VPC를 검사하고 DNS 구성을 확인하십시오.

  1. VPC 를 여십시오.
  2. 대중교통 VPC에는 DNS-Hub 표시기가 설정되어 있습니다.
  3. 각 스포크 VPC에는 DNS-Shared 표시기가 설정되어 있습니다.
  4. 스포크 VPC중 하나를 클릭하십시오.
    1. 선택적 DNS 설정 으로 화면이동하십시오.
    2. DNS 분석기 설정 트위스티를 열고 DNS 분석기 유형이 delegated 이고 DNS 분석기 서버가 전송 VPC 10.1.15.x, 10.2.15.y, 10.2.15.z 에 있음을 확인하십시오.
    3. DNS 분석 바인딩 트위스티를 열고 DNS 허브 VPC가 전송 VPC로 설정되어 있는지 확인하십시오.

DNS 테스트

pytest 스크립트에서 사용 가능한 curl DNS 테스트 세트가 있습니다. 이러한 테스트는 원격의 DNS 이름을 사용하여 curl됩니다. 많은 수의 테스트가 있으므로 테스트를 병렬로 실행하십시오.

pytest -n 10 -m dns

가상 사설 엔드포인트 게이트웨이

VPC는 Virtual Private Endpoint (VPE) for VPC 을 통해 IBM Cloud Services에 대한 개인용 액세스를 허용합니다. VPE 게이트웨이는 표준 IBM Cloud VPC 제어를 통해 세분화된 네트워크 액세스 제어를 허용합니다.

각 VPC VPE 게이트웨이에 대해 DNS 구역이 작성됩니다. DNS 구역은 VPC와 연관된 개인용 DNS 서비스에 자동으로 추가됩니다. 각 스포크 VPC에는 전송 VPC에 대한 DNS 구성 bound 가 있습니다. 이를 통해 스포크 VPE DNS 구역을 전송 VPC에 공유할 수 있습니다.

가상 사설 엔드포인트 게이트웨이 추가
가상 사설 엔드포인트 게이트웨이 추가

  1. vpe_transit_tf및 vpe_론 _tf 계층을 적용하여 전송 및 각 스포크 VPC에 대해 IBM Cloud Databases for PostgreSQL 인스턴스 및 VPE를 작성하십시오.

    ./apply.sh vpe_transit_tf vpe_spokes_tf
    
  2. pytest 스크립트에서 사용 가능한 vpevpedns 테스트 세트가 있습니다. vpedns 테스트는 Databases for PostgreSQL 인스턴스의 DNS 이름이 엔클로징 VPC의 개인용 CIDR 블록 내에 있는지 확인합니다. vpe 테스트는 psql 명령을 실행하여 Databases for PostgreSQL 인스턴스에 원격으로 액세스합니다. 스포크 0구역 1에서 vpe및 vpedns 테스트:

    • 예상 결과 모든 테스트 패스
    pytest -m 'vpe or vpedns' -k spoke0-z1
    

이제 이 학습서의 모든 테스트를 통과해야 합니다. 꽤 많은 수가 있습니다. 다음과 같이 병렬로 실행하십시오.

pytest -n 10

프로덕션 참고사항 및 결론

IBM Cloud for Financial Services에 대한 VPC 참조 아키텍처 에는 IBM Cloud의 워크로드 보안에 대한 훨씬 더 자세한 정보가 있습니다.

다음과 같은 몇 가지 명백한 변경사항이 있습니다.

  • CIDR 블록은 명확성 및 설명의 용이성을 위해 선택되었다. 다중 구역 지역의 가용성 구역은 주소 공간을 보존하기 위해 10.1.0.0/10, 10.64.0.0/10, 10.128.0.0/10 일 수 있습니다. 마찬가지로, 작업자 노드의 주소 공간은 방화벽, DNS및 VPE 공간의 비용으로 확장될 수 있습니다.
  • 작업자 VSI, 가상 사설 엔드포인트 게이트웨이, DNS 위치 및 방화벽에 대한 각 네트워크 인터페이스의 보안 그룹은 모두 신중하게 고려해야 합니다.
  • 각 서브넷에 대한 네트워크 액세스 제어 목록은 신중하게 고려해야 합니다.
  • SSH를 통한 연결 테스트를 지원하기 위해 유동 IP가 모든 테스트 인스턴스에 연결되었습니다. 이는 프로덕션에서 필요하거나 바람직하지 않습니다.
  • 컨텍스트 기반 제한사항을 구현 하여 모든 자원에 대한 액세스를 추가로 제어하십시오.

이 튜토리얼에서는 허브 VPC및 스포크 VPC 세트를 작성했습니다. 전송 VPC 방화벽 라우터를 통해 모든 교차 VPC 트래픽을 라우팅했습니다. 전송 VPC 허브에 대한 DNS 서비스가 작성되었으며 각 스포크 VPC는 전송 VPC에 바인드된 DNS입니다.

자원 제거

./apply.sh 명령을 사용하여 모든 디렉토리에서 terraform destroy 를 역순으로 실행하십시오.

./apply.sh -d : :

튜토리얼 확장

사용자의 아키텍처는 제시된 아키텍처와 동일하지 않을 수 있지만, 여기서 설명하는 기본 컴포넌트에서 구성될 수 있습니다. 이 학습서를 펼치기 위한 아이디어: