우리는 현재 VPC 내에서 AWS Lambda 함수를 실행하고 있으며, 예를 들어 VPC 내의 AWS Lambda가 MongoDB Atlas 호스팅 데이터베이스와 통신할 수 있도록 MongoDB Atlas에 대한 피어링 연결이 이미 설정되어 있습니다.
이제 AWS Lambda에 의해 트리거되고 동일한 VPC 내에서 실행되는 VPC 내의 특정 서비스가 VPN을 통해 온프레미스 네트워크 기능/호스트에 액세스해야 한다는 요구 사항이 생겼습니다. 또한 해당 네트워크는 해당 서비스에 대한 메시지에 응답할 수 있어야 하므로 사이트 간 연결이 필요하다고 가정합니다.
고객은 IKE 1단계 매개변수, IKE 2단계 매개변수(IPSEC), 로컬 피어 IP 주소, 허용되는 VPN 통신 포트 및 로컬 암호화 도메인을 제공했습니다.
그들은 이제 원격 피어 IP 주소와 원격 암호화 도메인을 요구하고 있습니다.
질문 1: 우리가 VPC의 AWS에서 실현 가능한 것을 달성하려고 하는 것입니다(이에 대해 상충되는 게시물을 읽고 있습니다.
질문 2: 터널 시작은 고객 측에서 발생해야 하며 그런 다음 네트워크 모니터링 폴링을 사용하여 터널을 활성 상태로 유지한다고 가정하는 것이 맞습니까?
답변1
질문 1에 관해서.
AWS 외부에 있는 리소스에 안전하게 연결하기 위해 IPSec 기반 VPN을 통해 연결하는 기능을 언급한다고 가정합니다. 대답은 '예'입니다. 그러나 이를 기본 AWS 구현에는 몇 가지 제한 사항이 있습니다. 첫 번째는 1단계 또는 2단계 구성 설정의 어떤 측면도 지정할 수 없다는 것입니다. 대신 AWS는 다양한 제조업체에 대해 사전 구성된 설정을 다운로드할 수 있는 기능을 제공할 뿐만 아니라 몇 가지 좋은 일반적인 예도 제공합니다.
좋은 자료는 다음과 같습니다:
AWS 관리형 VPN 연결- AWS VPN Gateway 서비스에 대한 세부 정보를 제공합니다.
고객 게이트웨이- AWS 외부의 디바이스에 필요한 설정에 대한 정보를 제공합니다.
질문 2에 관해서.
이는 사실입니다. 어떤 이유로든 터널이 끊어지면 AWS 측에서 터널을 시작할 수 없습니다(이는 매우 짜증나는 제한 사항입니다). 그러나 주변에 방법이 있습니다. 일부 장치는 터널을 유지하기 위해 연결 유지 패킷 전송을 지원합니다. 예를 들어 Cisco ASA는 IP SLA 기능을 사용하여 터널을 따라 SLA 메시지를 보내 이를 유지할 수 있습니다. 에서 추출샘플 ASA 구성:
터널을 활성 상태 또는 항상 작동 상태로 유지하려면 ASA는 acl-amzn에 정의된 서브넷으로 트래픽을 보내야 합니다. SLA 모니터링은 서브넷의 대상으로 ping을 보내고 터널을 활성 상태로 유지하도록 구성할 수 있습니다. 이 트래픽은 응답을 반환할 대상으로 전송되어야 합니다. 이는 외부 인터페이스에서 제공되는 ASA에서 대상으로 ping을 전송하여 수동으로 테스트할 수 있습니다. 핑의 가능한 대상은 VPC 내의 인스턴스입니다. 중복성을 위해 여러 SLA 모니터를 여러 인스턴스로 구성하여 단일 실패 지점으로부터 보호할 수 있습니다.
또는 cron 작업이나 예약된 작업을 통해 주기적으로 핑을 보내도록 한쪽 시스템을 간단하게 구성할 수도 있습니다.
그러나 또 다른 옵션은 자체 IPSec 게이트웨이를 AWS에 배포하는 것입니다. 인스턴스 자체에서 실행하거나 다른 인스턴스에서 실행한 다음 서브넷의 라우팅 테이블을 업데이트하여 이 인스턴스를 통해 외부 AWS 서브넷으로 라우팅할 수 있습니다. 이를 통해 IPSec 설정 및 동작을 더 효과적으로 제어할 수 있지만 기본 AWS 서비스에 비해 관리하기가 더 복잡합니다.