목표

• VPC 기반 허브 및 스포크 모델의 개념을 이해합니다.
• 방화벽 라우터 및 전송 VPC 환경의 구현을 이해합니다.
• VPC 유입 및 유출 라우팅을 이해합니다.
• 비대칭 라우팅 문제를 식별하고 선택적으로 해결합니다.
• Transit Gateway를 통해 VPC를 연결하십시오.

시작하기 전에

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

• terraform: 인프라를 코드로 사용하여 리소스를 프로비저닝함
• python 를 사용하여 선택적으로 pytest 명령을 실행하십시오.
• 방화벽 라우터를 구현하려면 IP 스푸핑 검사를 사용으로 설정 해야 합니다.
• 가상 서버에 연결하기 위한 SSH 키입니다. SSH 키가 없는 경우, VPC용 키를 생성하는 방법을 따르십시오.

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

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

• 사용자 권한을 확인하십시오. 사용자 계정에 이 학습서의 모든 자원을 작성하고 관리할 수 있는 충분한 권한이 있는지 확인하십시오. 다음 목록을 참조하십시오.
  • VPC에 대한 필수 권한.
  • Transit Gateway.
  • IP 스푸핑 검사에 필요한 권한.

IP 주소 및 서브넷 레이아웃

이 단계에서는 VPC 네트워크 리소스를 프로비저닝합니다. VPC에 대한 주소 지정 계획을 디자인 하여 신중하게 계획하고 겹치지 않는 CIDR 블록을 사용하십시오.

먼저 CIDR 공간을 VPC로 나누는 것이 좋지만 이로 인해 라우팅이 복잡해집니다. 대신 가용성 구역을 단일 CIDR 블록으로 간주하고 각 VPC를 이의 조각을 이용하는 것으로 간주하십시오.

이 다이어그램은 구역 1만자세히 표시합니다. 서브넷 크기 및 레이아웃은 다른 구역에서 동일합니다.

엔터프라이즈는 왼쪽에 있고 IBM Cloud 은 오른쪽에 있습니다. 단순한 경우 IBM Cloud 에서 전송 VPC및 Spoke 0에 대해 단일 구역이 묘사됩니다. CIDR 블록은 겹치지 않으며 VPC는 모두 각 구역에서 CIDR 블록을 이용합니다.

• 온프레미스 CIDR은 192.168.0.0/16입니다.
• 이 다중 구역 지역 의 구역은 10.*.0.0/16입니다. 두 번째 숫자: 1, 2, 3은 구역 번호입니다(댈러스/미국-남부의 경우 표시됨):
  • 10.10.1.0.0/16, 구역 1, 댈러스 1, us-south-1.
  • 10.10.2.0.0/16, 구역 2, 댈러스 2, us-south-2.
  • 10.10.3.0.0/16, 구역 3, 댈러스 3, us-south-3.
• 대중교통 VPC는 CIDR 10.*.15.0/24: 을 이용합니다.
  • 10.1.15.0/24, 구역 1.
  • 10.2.15.0/24, 구역 2.
  • 10.3.15.0/24, 구역 3.
• 스포크 0은 10.*.0.0/24 또는 CIDR을 이용합니다.
  • 10.1.0.0/24, 구역 1.
  • 10.2.0.0/24, 구역 2.
  • 10.3.0.0/24, 구역 3.
• 서브넷 CIDR은 추가로 /24를 /26으로 나눕니다.

전송 및 스포크의 서브넷은 서로 다른 자원 유형에 대한 것입니다.

• 작업자-네트워크 액세스 가능 컴퓨팅 리소스 VPC 인스턴스, 로드 밸런서, Red Hat OpenShift등 이 학습서에서는 VPC 인스턴스에 대해 설명합니다.
• dns-파트 2에서 사용되는 DNS Services 위치 어플라이언스입니다.
• vpe-파트 2에서 사용된 VPE for VPC.
• fw-firewall-router VPC 인스턴스 (전송 중에만).

VPC 네트워크 리소스 프로비저닝

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 를 편집하고 해당 파일의 주석을 안내서로 사용하십시오.

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

   ./apply.sh
   

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

   ./apply.sh -p : :
   

   다음과 같이 표시됩니다.

   directories: config_tf enterprise_tf transit_tf spokes_tf transit_spoke_tgw_tf test_instances_tf test_lbs_tf enterprise_link_tf firewall_tf transit_ingress_tf spokes_egress_tf all_firewall_tf all_firewall_asym_tf dns_tf vpe_transit_tf vpe_spokes_tf power_tf
   

6. 아직 가지고 있지 않다면, 플랫폼 API 키 를 구해서 Terraform에서 사용할 수 있도록 API 키를 내보내십시오

   export IBMCLOUD_API_KEY=YourAPIKEy
   

7. 이 첫 번째 단계에서는 config_tf, enterprise_tf, transit_tf, up_tf및 transit_spoke_tgw_tf에 적용됩니다.

   ./apply.sh : transit_spoke_tgw_tf
   

VPC및 서브넷이 작성되었습니다. 전송 VPC및 스포크 VPC가 프로비저닝된 Transit Gateway를 통해 연결되었습니다. 브라우저에서 Virtual Private Clouds 를 여십시오. 전송 VPC를 열고 주소 접두부 및 서브넷에 대한 CIDR 블록을 기록해 두십시오. 엔터프라이즈 및 스포크 VPC도 조사하십시오. Transit Gateway 를 열고 Transit Gateway를 클릭하여 Transit VPC와 스포크 VPC간의 연결을 확인하십시오.

테스트 인스턴스 작성

VPC 가상 서버 인스턴스, VSI는 네트워크 연결을 테스트하기 위해 프로비저닝됩니다. 엔터프라이즈, 전송 및 각 스포크의 각 작업자 서브넷 (구역당 하나) 에 테스트 인스턴스가 추가됩니다. 3개구역과 2개스포크의 기본 구성이 사용되는 경우 12개의 인스턴스가 프로비저닝됩니다.

1. 테스트 인스턴스 작성

   ./apply.sh test_instances_tf
   

IBM Cloud 콘솔의 각 단계에서 작성된 자원을 탐색하는 것이 좋습니다. 선택적으로 가상 프라이빗 클라우드 를 여십시오. 왼쪽에서 가상 서버 인스턴스 를 클릭하고 작성된 인스턴스를 확인하십시오.

테스트

이 학습서는 한 번에 한 계층씩 통신 경로를 추가합니다. pytest 테스트 스위트는 통신 경로를 철저하게 테스트하는 데 사용됩니다. 학습서가 끝날 때까지 모든 테스트가 통과할 것으로 예상됩니다.

리더가 pytest 를 사용하여 결과를 확인할 필요는 없습니다. 학습서를 따라가서 계층을 적용하고 학습서에 설명된 결과를 신뢰하십시오. 리더는 VSI, 서브넷 및 라우팅 테이블과 같은 VPC 리소스가 작성된 후에도 여전히 이를 탐색할 수 있습니다.

각 pytest 테스트는 인스턴스 중 하나에 SSH로 연결하고 연결 테스트 유형을 수행합니다 (예: 다른 인스턴스 중 하나에 대해 curl 명령 실행). 기본 SSH 환경은 인스턴스에 로그인하는 데 사용됩니다. 예기치 않은 테스트 결과가 표시되면 pytest 문제점 해결 섹션을 시도하십시오.

1. -m (마커) 플래그를 사용하여 스위트에서 구역 1 curl 테스트를 실행하십시오. curl, lz1 (왼쪽 구역 1) 및 rz1 (오른쪽 구역 1) 로 표시된 테스트를 선택하십시오.

   예상 결과는 다음과 같습니다. 엔터프라이즈 <-> 엔터프라이즈와 같은 VPC내의 연결은 PASSED 입니다. 전송과 스포크 간의 연결은 전달됩니다. 엔터프라이즈 - > 전송 또는 스포크의 교차 VPC는 FAILED 입니다.

   pytest -m "curl and lz1 and rz1"
   

   아래는 예시 출력입니다:

   root@ea28970e0897:/usr/src/app# pytest -m "curl and lz1 and rz1"
   ===================================================== test session starts ======================================================
   platform linux -- Python 3.12.3, pytest-8.1.1, pluggy-1.4.0 -- /usr/local/bin/python
   cachedir: .pytest_cache
   rootdir: /usr/src/app
   configfile: pytest.ini
   testpaths: py
   plugins: xdist-3.5.0
   collected 36 items / 20 deselected / 16 selected
   
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-enterprise-z1-worker] PASSED                                   [  6%]
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-transit-z1-worker] FAILED                                      [ 12%]
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke0-z1-worker] FAILED                                       [ 18%]
   py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke1-z1-worker] FAILED                                       [ 25%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-enterprise-z1-worker] FAILED                                      [ 31%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-transit-z1-worker] PASSED                                         [ 37%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-spoke0-z1-worker] PASSED                                          [ 43%]
   py/test_transit.py::test_curl[l-transit-z1-worker -> r-spoke1-z1-worker] PASSED                                          [ 50%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-enterprise-z1-worker] FAILED                                       [ 56%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-transit-z1-worker] PASSED                                          [ 62%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-spoke0-z1-worker] PASSED                                           [ 68%]
   py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-spoke1-z1-worker] PASSED                                           [ 75%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-enterprise-z1-worker] FAILED                                       [ 81%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-transit-z1-worker] PASSED                                          [ 87%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-spoke0-z1-worker] PASSED                                           [ 93%]
   py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-spoke1-z1-worker] PASSED                                           [100%]
   
   =================================================== short test summary info ====================================================
   FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-transit-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke0-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke1-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-transit-z1-worker -> r-enterprise-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-enterprise-z1-worker] - assert False
   FAILED py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-enterprise-z1-worker] - assert False
   ========================================= 6 failed, 10 passed, 20 deselected in 38.76s =========================================
   

네트워크 구성을 변경하면 기본 VPC 네트워크 시스템이 일관성을 유지하기 위해 몇 가지 테스트 실행을 수행할 수 있습니다. 예상 결과가 표시되지 않으면 처음에 테스트를 두 번 다시 실행할 준비가 되어 있어야 합니다.

r- 및 l- 은 r ight및 l eft를 나타냅니다. 이름의 중간 부분은 enterprise, transit, spoke0, spoke1, ... 을 식별합니다. z1, z2, ... 는 구역을 식별합니다. 테스트는 왼쪽 인스턴스에 SSH로 연결됩니다. 왼쪽 인스턴스에서 오른쪽 인스턴스에 대한 연결이 시도됩니다. test_curl 은 왼쪽 인스턴스에서 오른쪽 인스턴스로 curl 연결을 수행합니다.

요약하면 test_curl[l-enterprise-z1 -> r-transit-z1] 테스트는 다음을 수행합니다.

1. 엔터프라이즈 구역 1의 테스트 인스턴스에 SSH하십시오.
2. curl to transit zone 1을 실행하십시오.
3. 리턴 문자열에 통과 또는 실패를 표시하기 위한 전송 구역 1의 ID가 포함되어 있음을 어설션합니다.

함께 제공되는 GitHub Repository 의 README.md 에는 세부사항 및 소스 코드가 있습니다.

Direct Link 및 Transit Gateway 를 통해 엔터프라이즈를 전송에 연결

Transit Gateway를 사용하여 IBM Cloud® Direct Link 를 프로비저닝하십시오.

IBM Cloud® Direct Link 은 엔터프라이즈를 IBM Cloud에 연결하기 위한 고속 보안 데이터 경로입니다. 이 학습에서 Transit Gateway 는 배포에 사용됩니다. Transit Gateway 의 사용은 온프레미스 연결에 대해 선택사항입니다.

이 학습서의 엔터프라이즈는 다른 VPC를 사용하여 시뮬레이션됩니다. Transit Gateway 를 통해 이 시뮬레이션된 엔터프라이즈 (실제로 다른 VPC) 를 연결하면 Direct Link에서 경험하는 것과 매우 유사한 경험을 얻을 수 있습니다.

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

   ./apply.sh enterprise_link_tf
   

2. -m (마커) 플래그를 사용하여 스위트에서 구역 1 curl 테스트를 실행하십시오. curl, lz1 (왼쪽 구역 1) 및 rz1 (오른쪽 구역 1) 로 표시된 테스트를 선택하십시오.

   예상 결과는 다음과 같습니다. VPC내의 연결, 전송 <-> 스포크, 엔터프라이즈 <-> 전송, 스포크 <-> 스포크는 통과하지만 엔터프라이즈 <-> 스포크는 실패합니다.

   pytest -m "curl and lz1 and rz1"
   

Transit NFV 방화벽을 통해 Spoke에 엔터프라이즈 연결-라우터

엔터프라이즈 <-> 클라우드 트래픽의 전송 VPC에 대한 인센티브는 일반적으로 네트워크 트래픽을 라우팅, 검사, 모니터 및 로그하는 것입니다. 이 단계에서 방화벽 라우터 어플라이언스는 전송 VPC의 각 구역에 설치됩니다.

NFV 라우터

방화벽 라우터 어플라이언스를 프로비저닝하십시오. Transit Gateway 에 대한 유입 라우트 테이블이 점선으로 표시된 대로 대중교통 VPC에 추가되었습니다. 방화벽 라우터를 보유하기 위해 전송 VPC의 각 구역에서 서브넷이 작성되었습니다.

엔터프라이즈에서 스포크로의 연결은 전송 VPC에서 네트워크 기능 가상화, NFV, 방화벽 라우터 인스턴스를 통해 이루어집니다. 프로덕션에서는 카탈로그에서 하나를 선택하거나 직접 가져올 수 있습니다. 이 데모에서는 커널 iptables가 설정된 Ubuntu 재고 이미지를 사용하여 모든 패킷을 소스에서 대상으로 전달합니다. 이 학습서에서는 방화벽 검사가 수행되지 않습니다.

Terraform 구성은 allow_ip_spoofing 을 사용하여 방화벽 라우터 인스턴스를 구성합니다. 계속하기 전에 IP 스푸핑 검사를 사용으로 설정 해야 합니다.

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

   ./apply.sh firewall_tf
   

2. 테스트 스위트를 실행하십시오.

   예상 결과는 다음과 같습니다. VPC, 엔터프라이즈 - > 전송, 엔터프라이즈 <-> 스포크 (spoke) 동일한 구역 패스. 그러나 비대칭 라우팅 문제로 인해 모든 전송 - > 스포크, 모든 전송 - > 엔터프라이즈가 실패합니다.

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

   이 튜토리얼의 파트 2 에서는 방화벽 라우터를 통해 모든 VPC <-> 다른 VPC 트래픽을 라우팅하고 이러한 문제를 해결합니다. 하지만 먼저 무슨 일이 일어나고 있는지를 배우는 것이 중요합니다.

대중교통 대상 트래픽에 대한 방화벽 제거

IBM Cloud VPC 는 보안 TCP 연결 추적을 위해 산업 표준 상태 기반 라우팅을 사용합니다. TCP 연결이 나가는 경로와 동일한 경로를 사용해야 합니다. 한 가지 예외는 Network Load Balancers 와 같은 라우터에서 사용되는 Direct Server Return입니다. 이를 사용하면 엔터프라이즈에서 수신되는 연결이 방화벽을 통과하여 전송 테스트 인스턴스로 전달된 후 시작한 사람에게 직접 리턴할 수 있습니다.

이는 Transit Gateway 를 통과한 후 다시 방화벽 라우터로 유입 라우팅을 통과하는 대중교통 테스트 인스턴스에서 시작되는 트래픽에 도움이 되지 않습니다. 이 연결은 방화벽 라우터 (3) 에 고정되며 아래 빨간색으로 표시된 대로 작업자에게 다시 전달되지 않습니다. 트래픽 전송 - > 엔터프라이즈 및 전송 - > 스포크가 실패합니다.

한 가지 가능한 솔루션은 전송 VPC로 향하는 트래픽을 방화벽 라우터로 전송하는 것을 중지하는 것입니다. 전송을 위한 광범위한 Ingress 라우트가 현재 방화벽 라우터로 트래픽을 라우팅하고 있습니다. 위임 에 대한 전송을 위해 보다 구체적인 라우트를 기본 동작으로 추가할 수 있습니다. 방화벽 라우터 대신 원하는 대상으로 직접 전송하십시오.

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

1. 엔터프라이즈 <-> 전송
2. 스포크 <-> 전송
3. 스포크 <-> 스포크
4. enterprise <--transit 방화벽-라우터--> spoke

Transit Ingress 라우트 테이블에 다음 라우트를 추가하여 이 라우팅을 수행할 수 있습니다.

1. 유입 라우트 테이블의 현재 값을 관찰하려면 IBM Cloud 콘솔에서 VPC에 대한 라우팅 테이블 을 방문하십시오. 드롭 다운에서 transit VPC를 선택한 후 tgw-ingress 라우팅 테이블을 선택하십시오.

2. transit_ingress 계층을 적용하여 라우팅 테이블을 변경하십시오.

./apply.sh transit_ingress_tf

1. 새 라우트를 관찰하려면 라우팅 테이블의 브라우저 표시를 새로 고치십시오.

2. 테스트 스위트를 실행하십시오.

   예상 결과는 다음과 같습니다. 모든 테스트의 결과는 PASSED 입니다.

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

구성에서 엔터프라이즈와 스포크 간에 교차 구역 트래픽이 플로우되는 방식을 참고하는 것은 흥미로운 일입니다. 엔터프라이즈는 전송 VPC에서 유입 라우팅을 통해 방화벽 라우터를 통해 올바른 구역으로 트래픽을 전송합니다. Transit Gateway 는 192.168.0.0/16 이 모든 구역에서 사용 가능하며 아래 다이어그램에 표시된 대로 스포크와 동일한 구역에서 광고된 엔터프라이즈 라우트를 사용하여 전송 VPC로 라우팅됨을 알게 되었습니다.

라우팅 요약

기본 라우팅이 완료되었습니다.

• 엔터프라이즈 <-> 전송
• 전송 <-> 스포크
• 엔터프라이즈 < -- (전송 방화벽-라우터)-- > 스포크

프로덕션 참고사항 및 결론

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

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

• CIDR 블록은 명확성 및 설명의 용이성을 위해 선택되었다. 다중 구역 지역의 가용성 구역은 주소 공간을 보존하기 위해 10.0.0.0/10, 10.64.0.0/10, 10.128.0.0/10 일 수 있습니다. 작업자 노드의 주소 공간은 방화벽, DNS및 VPE 공간의 비용으로 확장될 수 있습니다.
• 작업자 VSI, 가상 사설 엔드포인트 게이트웨이, DNS 위치 및 방화벽에 대한 각 네트워크 인터페이스의 보안 그룹은 모두 신중하게 고려해야 합니다.
• 각 서브넷에 대한 네트워크 액세스 제어 목록은 신중하게 고려해야 합니다.

SSH를 통한 연결 테스트를 지원하기 위해 유동 IP가 모든 테스트 인스턴스에 연결되었습니다. 이는 프로덕션에서 필요하거나 바람직하지 않습니다.

컨텍스트 기반 제한사항을 구현 하여 모든 자원에 대한 액세스를 추가로 제어하십시오.

이 튜토리얼에서는 허브 VPC및 스포크 VPC 세트를 작성했습니다. 아키텍처에 필요한 가용성 구역을 식별하고 VPC에서 서브넷 세트를 작성했습니다. 트래픽을 전달하기 위해 각 구역에서 전송 VPC 방화벽 라우터를 작성했습니다. 테스트 인스턴스를 사용하여 연결을 확인하고 잠재적인 문제점을 식별했습니다. 라우팅 테이블 라우트는 필요한 트래픽 경로를 식별하는 데 사용되었습니다.

자원 제거

이 학습서의 두 번째 파트를 계속하려는 경우 자원을 제거할 필요가 없습니다.

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

./apply.sh -d : spokes_egress_tf

튜토리얼 확장

모든 교차 VPC 트래픽이 방화벽 라우터를 통해 라우팅되고 VPE for VPC DNS가 검사되는 이 튜토리얼의 파트 2 로 계속 진행하는 것이 좋습니다.

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

• IBM Cloud® Internet Services 을 사용하여 수신 공용 인터넷 액세스를 통합합니다.
• 대중교통에서 플로우 로그 캡처 를 추가하십시오.
• 엔터프라이즈 의 개별 계정에 각 스포크를 넣으십시오.
• 일부 스포크가 방화벽을 통과하고 일부는 방화벽을 통과하지 않는 스포크 트래픽을 강제 실행합니다.
• 작업자 VSI를 Red Hat OpenShift on IBM Cloud 및 VPC 로드 밸런서 로 대체하십시오.
• 전송 VPC의 방화벽 및 퍼블릭 게이트웨이 를 통해 모든 아웃바운드 트래픽을 강제 실행합니다.

관련 컨텐츠

• IBM Cloud for Financial Services
• 여러 위치 및 지역에 격리된 워크로드를 배치하는 방법
• 가상 프라이빗 클라우드의 퍼블릭 프론트 엔드 및 프라이빗 백엔드,
• 네트워크 기능 가상화
• 투명한 VNF및 스포크 대 스포크 트래픽을 사용하는 사설 허브 및 스포크