사이트 간 가상 사설망(VPN)은 수십 년 동안 분산 네트워크를 연결하는 데 사용되었습니다. 이 게시물에서는 전송 허브 및 스포크 아키텍처에서 VPC VPN 게이트웨이를 사용하여 온프레미스(엔터프라이즈) 네트워크를 IBM Cloud VPC에 연결하는 방법을 설명합니다.
VPC 전송 허브 및 스포크에 대한 VPN Gateway 연결.
각 스포크는 다른 사업부나 팀에서 운영할 수 있습니다. 팀은 애플리케이션 또는 VPC RedHat OpenShift IBM Cloud 클러스터를 실행하는 가상 서비스 인스턴스와 같은 VPC 리소스에 대한 엔터프라이즈 액세스를 허용할 수 있습니다. 데이터베이스와 같은 VPE 지원 서비스에 대한 개인 기업 액세스도 VPN 게이트웨이를 통해 가능합니다. 이 방법을 사용하면 클라우드 리소스의 사용 용이성과 탄력성을 누릴 수 있으며 VPN을 통해 리소스에 안전하게 액세스하여 필요한 만큼만 비용을 지불할 수 있습니다.
VPC Transit Hub 및 Spoke 아키텍처 자습서를 통한 Centralize 통신은 몇 달 전에 게시되었습니다. 컴패니언 GitHub 리포지토리는 IBM Direct Link 시뮬레이션을 대체하기 위해 정책 모드 VPC VPN 게이트웨이를 선택적으로 지원하도록 수정되었습니다.
다중 구역 지역(MZR) 설계
전송 허브 설계는 IBM 다중 구역 지역(MZR)과 통합되며 VPN 게이트웨이는 구역별로 다릅니다. 신중한 연구 끝에 아래 표시된 영역 아키텍처가 구현되었습니다. 두 개의 영역만 표시되지만 세 개로 확장할 수 있습니다.
VPN 게이트웨이 영역 연결.
노트:
- VPN 게이트웨이는 각 영역에 연결됩니다. Enterprise CIDR 블록은 특정 클라우드 영역 VPN Gateway에 연결됩니다. 엔터프라이즈 CIDR 블록은 192.168.0.0/24로 좁습니다. 클라우드 CIDR 블록은 광범위하며 전체 클라우드(모든 VPC 및 모든 영역)를 포함합니다(10.0.0.0/8).
- 엔터프라이즈 영역을 나타내는 VPC 주소 접두사가 전송 VPC에 추가됩니다. 가상 주소 접두사를 사용하여 스포크가 트래픽을 엔터프라이즈로 라우팅하는 방법을 자습서에서 확인하십시오.
- 이 예제에 설명된 대로 VPC 수신 라우팅 테이블이 전송 VPC에 추가됩니다. VPN 게이트웨이 어플라이언스를 통해 엔터프라이즈로 향하는 스포크의 모든 인그레스 트래픽을 자동으로 라우팅합니다.
TLDR 섹션에 있는 동반 GitHub 리포지토리의 단계를 따르십시오. config_tf/terraform.tfvars 파일을 편집할 때 다음 변수가 구성되었는지 확인하십시오.
config_tf/terraform.tfvars:
enterprise_phantom_address_prefixes_in_transit = 참 vpn = 참 방화벽 = 거짓
설정도 고려 make_redis = 참 연결된 가상 프라이빗 엔드포인트 게이트웨이 연결과 전송 및 스포크를 위한 Redis 인스턴스 프로비저닝을 허용합니다. 구성된 경우 스포크의 프라이빗 Redis 인스턴스도 엔터프라이즈에서 액세스할 수 있습니다. 개인 DNS 구성 및 전달에 대한 세부 정보는 자습서 2부의 이 섹션에서 다룹니다.
모든 계층이 적용되면 테스트를 실행합니다(필요한 경우 Python 구성에 대한 GitHub 리포지토리 README.md의 특별 참고 사항 참조). 모든 테스트를 통과해야 합니다.
파이썬 설치 -r requirements.txt pytest
엔터프라이즈-트랜짓 교차 영역 라우팅에 대한 참고 사항
초기 디자인은 엔터프라이즈 <> 스포크에 적합했습니다. 동일한 영역 내의 엔터프라이즈 <> 전송도 작동했습니다. 그러나 엔터프라이즈 <> 전송 교차 영역 라우팅 실패를 해결하려면 추가 구성이 필요합니다.
VPN Gateway 교차 영역 라우팅.
추가 교차 영역 VPN 게이트웨이 연결이 없으면 전송 VPC의 기본 라우팅 테이블에서 교차 영역 엔터프라이즈로의 반환 VPC 라우팅 테이블 항목이 없습니다(빨간색 선 참조). VPN Gateway 연결은 전송 VPC의 기본 라우팅 테이블에 자동으로 경로를 추가하지만 VPN Gateway가 포함된 영역에만 추가합니다. 위의 다이어그램에서 작업자 10.2.0.4는 192.168.0.4로 돌아갈 경로가 없습니다.
전송 VPC 영역에 대한 추가 교차 영역 연결로 파란색 선으로 표시된 것처럼 이 문제가 해결되었습니다.
결론
사이트 간 VPN은 엔터프라이즈를 다중 구역 지역의 IBM Cloud VPC에 연결하는 데 필요한 기술일 수 있습니다. 이 게시물에 설명된 단계를 사용하여 기업을 클라우드에 완전히 연결하는 데 필요한 VPN 게이트웨이 수를 최소화할 수 있습니다. Virtual Private Endpoint Gateway를 통해 액세스할 수 있는 카탈로그의 Virtual Server Instances 및 리소스와 같은 VPC 리소스에 대한 비공개 연결을 즐기십시오.
IBM Cloud VPC에 대해 자세히 알아보기