EC2 가용 영역 전반: VPN 전에 라우팅을 확인하세요

두 EC2 인스턴스 사이에 VPN 소프트웨어를 설치하기 전에 한 가지 질문에 답하세요. 두 인스턴스가 같은 VPC에 있습니까? 그렇다면 프라이빗 경로는 이미 존재하며 영역을 넘는 배치가 그것을 바꾸지 않습니다. 이 상황에서 작업의 대부분은 각 서브넷이 실제로 어떤 라우팅 테이블을 사용하는지 확인하고, 그다음 장애가 애초에 라우팅 문제였는지 파악하는 것입니다. 이 특정 질문에 터널은 대개 잘못된 답입니다.

확인 1: 같은 VPC인가, 다른 VPC인가

VPC는 리전 단위이며 가용 영역에 걸쳐 있고, 각 서브넷은 정확히 하나의 영역에 속합니다. 한 VPC의 서로 다른 영역에 있는 두 인스턴스도 여전히 같은 프라이빗 라우팅 도메인 안에 있습니다.

서로 다른 VPC는 리전이나 영역 레이블을 공유한다는 이유만으로 프라이빗 경로를 얻지 못합니다. 그런 경우에는 지원되는 연결과 별도의 경로 및 권한 작업이 필요하며, 이는 별개의 결정입니다.

확인 2: 서브넷 라우팅 테이블이 말하는 것

구성을 실제 값으로 적어 두세요. VPC 10.60.0.0/16 에 서브넷 10.60.1.0/24 과 10.60.2.0/24 이 있으면 인스턴스 10.60.1.10 과 10.60.2.20 에 VPC의 로컬 경로를 통한 경로가 주어집니다.

그다음 처음 찾은 테이블만이 아니라 두 서브넷에 연결된 테이블을 모두 확인하세요. 더 구체적인 검사 또는 어플라이언스 경로가 기본 경로를 덮어쓸 수 있고, 로컬 경로의 대상 자체도 최신 구성에서는 대체될 수 있습니다. 콘솔 어딘가에 로컬 경로가 보인다고 해서 두 워크로드가 모두 그것을 사용한다는 증거는 아닙니다.

VPC가 실제로 할당하는 프라이빗 주소와 이름을 사용하세요. 프라이빗 주소가 10으로 시작할 필요는 없으며, 기억으로 하나를 만들어 내는 것이 바로 동작하는 환경을 잘못 진단하는 방식입니다.

확인 3: 라우팅인가, 권한 부여인가

라우팅은 패킷을 대상의 네트워크 인터페이스까지만 전달합니다. 대상의 보안 그룹은 여전히 소스와 서비스를 허용해야 하고, 소스의 송신 규칙은 요청을 허용해야 하며, 네트워크 ACL이 있다면 양방향을 모두 허용해야 합니다. ACL은 상태를 저장하지 않기 때문입니다.

그 뒤에는 게스트 방화벽, 리스너 바인딩, 애플리케이션 자체의 ID가 있습니다. 어느 것이든 라우팅이 완벽하게 전달한 요청을 거부할 수 있습니다.

수락은 실제 애플리케이션 작업이어야 합니다. ping 성공은 애플리케이션 접근을 허용하지 않고 TLS 이름과 자격 증명이 올바른지도 증명하지 않으며, ping 차단은 모든 프라이빗 서비스가 중단되었음을 입증하지 않습니다.

확인 4: 별도 연결이 정말 필요한가

VPN이 설계에 포함될 수는 있지만, 명시된 이유가 있을 때입니다: 이 VPC를 사무실에 연결하거나, 노트북을 허용하거나, 오버레이 요구 사항을 충족하는. 그 이유는 같은 VPC 내부의 일반적인 통신과 다릅니다.

VPC가 무엇이 아닌지도 기억하세요. VPC는 가정용 이더넷 세그먼트의 확장이 아닙니다. 브로드캐스트 검색에 의존하는 애플리케이션은 별도로 평가할 요구 사항이 있습니다. 그것은 라우팅 버그가 아니라 설계의 공백입니다.

확인 5: 암호화 질문

프라이빗 주소와 허용 규칙은 애플리케이션 계층의 암호화 보호에 대해 아무것도 말하지 않습니다. 데이터에 종단 간 보호가 필요하다면, 그것은 서비스가 실제로 지원하는 프로토콜과 ID 모델에서 나옵니다.

설계 노트에서 네트워크 계층과 애플리케이션 계층의 주장을 분리하세요. 둘을 합치면 아무도 구현하지 않은 보호를 리뷰가 주장하게 됩니다.

무엇을 기록할까

두 서브넷 ID, 각각에 연결된 라우팅 테이블, 보안 그룹 참조, 그리고 테스트한 애플리케이션 작업을 기록하세요. 이것은 네 가지 사실이며, 이 경로에 대한 앞으로의 논쟁 대부분을 정리합니다.

영역 배치만으로는 VPN을 추가해야 한다고 말해 주지 않으며, 프라이빗 요청이 왜 실패했는지도 결코 설명하지 않습니다.