ELB는 AWS에서 발신 응답 트래픽도 라우팅합니까?

퍼블릭 / 프라이빗 서브넷이있는 AWS VPC에서 라우팅이 작동하는 방식을 이해하려고 노력했습니다.

퍼블릭 서브넷에서 ELB 및 NAT를 사용하고 프라이빗 서브넷에서 웹 서버를 사용하여 Amazon에서 권장하는 설정이 있습니다. http://blogs.aws.amazon.com/security/blog/tag/NAT에 따라 구성된 보안 그룹 (SG)이 있으며 모두 예상대로 작동합니다. 큰!

아직 이해하지 못하는 것은 위 아키텍처의 웹 서버 인스턴스에서 HTTP 응답이 반환되는 방식입니다.

따라서 웹 요청은 HTTP를 통해 공개 인터넷에서 들어오고, 80은 ELB에 도달하고 ELB는 웹 서버의 개인 IP로 가져갑니다. 이제 웹 서버가 응답해야합니다. 내가 이해 한 바에 따르면 응답은 다른 높은 TCP 포트 (1024-65535)를 통해 이루어집니다. NAT SG는 포트 80 및 443을 통한 아웃 바운드 트래픽 만 허용합니다. 따라서이 응답은 공용 인터넷으로 어떻게 다시 전달됩니까? NAT를 통과 할 수 없습니다. 이는 회신이 ELB를 통해 다시 전달됨을 의미합니다. Amazon 다이어그램은 ELB 트래픽 방향 화살표를 양방향으로 나타내지 않으며 ELB 설명서에 ELB가 상태 저장 NAT처럼 동작한다고 명시하지 않습니다. 그렇습니까?

amazon-web-services nat amazon-vpc

— 알리
소스

답변:

다이어그램의 화살표는 트래픽 흐름이 아니라 연결 설정 방향 만 나타냅니다.

예, 반품 트래픽은 ELB를 통해 되돌아갑니다.

그러나 이는 상태 저장 NAT가 아니며 TCP 연결 프록시입니다. ELB 시스템은 구성된 청취 포트에서 TCP 연결을 승인하고 SSL 세션이 구성된 경우이를 종료하고 백엔드 서버에 대한 새로운 TCP 연결을 설정합니다. 리스너가 HTTP에 대해 구성된 경우 ELB는 페이로드 인식 모드에서 작동하여 HTTP 요청을 백엔드로 구문 분석, 로깅 및 전달합니다. 각 수신 연결 및 "파이프를 함께 묶기"(HTTP 레벨 인식 또는 수정없이)

어느 쪽이든 응용 프로그램으로 들어오는 연결의 원본 주소는 원래 클라이언트가 아니라 ELB 노드의 원본 주소가됩니다. 클라이언트에게 리턴하기 위해 응답 트래픽이 ELB로 리턴되는 방법입니다.

http 모드에서 ELB는X-Forwarded-For 헤더 를 추가 (또는 추가) 하여 응용 프로그램이 원래 클라이언트 IP를 식별 할 수있을뿐만 아니라 X-Forwarded-Proto: [ http | https ]클라이언트 연결이 SSL을 사용하는지 여부와 X-Forwarded-Port프론트 엔드 포트를 표시 할 수 있습니다.

업데이트 : 위는 현재 "ELB Classic"또는 ELB / 1.0으로 알려진로드 밸런서 유형을 나타냅니다 (HTTP 상태 확인과 함께 보내는 사용자 에이전트 문자열에 있음).

최신 Layer 7 밸런서, Application Load Balancer 또는 ELB / 2.0은 트래픽 흐름과 관련하여 유사하게 작동합니다. 계층 4 ( "투명한"TCP) 기능이 ALB에서 제거되었으며 계층 7 기능이 크게 향상되었습니다.

최신 유형의로드 밸런서 인 Network Load Balancer는 레이어 3 밸런서입니다. 다른 두 가지와 달리 동적 NAT와 매우 유사하게 작동하며 인바운드 (외부에서 시작된) 연결 만 처리하고 EIP-addr + port를 통해 source-addr + port를 EIP-addr + port를 통해 instance-private-ip : adde + port로 매핑합니다. 다른 두 가지 유형의 밸런서와 달리 인스턴스는 퍼블릭 서브넷에 있어야하며이를 위해 자체 퍼블릭 IP를 사용해야합니다.

개념적으로 말하면 Network Load Balancer는 실제로 인터넷 게이트웨이의 동작 (즉, 비활성화, 교체 또는 의미있는 의미에서 실패를 경험할 수없는 논리적 개체)의 동작을 수정하는 것으로 보입니다. 이것은 실제로 "숨겨진"EC2 인스턴스에서 작동하는 ELB 및 ALB와 대조적입니다. NLB는 네트워크 인프라 자체에서 모든 모습으로 작동합니다.

— 마이클-sqlbot
소스

감사. 페이로드 인식, 페이로드 인식 모드에 대해 자세히 설명해 주시겠습니까? 또한 웹 서버가 원래 연결이 SSL을 통한 것인지 알 수 있습니까?

— Ali

이 요점을 해결하기 위해 답변에 추가 정보를 추가했습니다.

— Michael-sqlbot

and unlike the other two types of balancers, the instances need to be on public subnets, and use their own public IPs for this.

나는 이것을 읽어서 매우 기쁘다. 이 정보에 대한 참조를 제공 할 수 있습니까?

— Felipe Alvarez

@FelipeAlvarez는 전체 그림이 훨씬 더 복잡하다는 것이 밝혀졌습니다. 이것이 가장 직관적 인 구성이지만 Network Load Balancer는 대상 인스턴스에서 TCP 스트림 (아마도 네트워크 상태 테이블을 통해)을 캡처하고 다시 작성하여 예상대로 작동 할 수있는 방식으로 실제 네트워크 인프라와 통합됩니다. 인스턴스는 이런 식으로 구성되지 않습니다. 대상 인스턴스는 VPC에 선언 된 기본 경로가 필요합니다. 반환 패킷에 대해서는 무시되지만 여전히 존재해야합니다. 기본 경로가 없으면 블랙홀이 생성됩니다.

— Michael-sqlbot 2014 년

NLB에 대한 AWS 설명서에 따르면 계층 3이 아닌 계층 4입니다. 또한 백엔드 또는 대상 서버가 퍼블릭 서브넷에있을 필요는 없습니다. 실제로 대상 그룹의 IP 주소 범위는 다음 중 하나 여야합니다. 다음은 가능한 대상 유형입니다.

instance 대상은 인스턴스 ID로 지정됩니다.

ip 대상은 IP 주소로 지정됩니다.

대상 유형이 ip 인 경우 다음 CIDR 블록 중 하나에서 IP 주소를 지정할 수 있습니다.

대상 그룹에 대한 VPC의 서브넷

10.0.0.0/8(RFC 1918)

100.64.0.0/10(RFC 6598)

172.16.0.0/12(RFC 1918)

192.168.0.0/16(RFC 1918)

중대한

공개적으로 라우팅 가능한 IP 주소는 지정할 수 없습니다.

이게 도움이 되길 바란다.

— RBP
소스