ELB cũng định tuyến lưu lượng truy cập trả lời đi trong AWS


8

Tôi đã cố gắng hiểu cách định tuyến hoạt động trong VPC AWS với các mạng con công cộng / riêng.

Tôi có một thiết lập theo khuyến nghị của amazon với ELB và NAT trong mạng con công cộng và máy chủ web trong mạng con riêng tư. Tôi có các nhóm bảo mật (SG) được định cấu hình theo http://blogs.aws.amazon.com/security/blog/tag/NAT và tất cả đều hoạt động như mong đợi. Tuyệt quá!

Kiến trúc tham chiếu với cấu hình Amazon VPC

Điều tôi chưa hiểu là cách trả lời HTTP được trả về từ phiên bản máy chủ web trong kiến ​​trúc trên.

Vì vậy, một yêu cầu web đến từ internet công cộng qua HTTP, 80 lần truy cập ELB và ELB đưa nó đến IP riêng của máy chủ web, thật tuyệt. Bây giờ các máy chủ web phải trả lời. Từ những gì tôi hiểu, trả lời sẽ qua một cổng TCP khác cao hơn (1024-65535). NAT SG chỉ cho phép lưu lượng truy cập đi qua các cổng 80 & 443. Vậy làm thế nào để trả lời này trở lại Internet công cộng. Nó không thể đi qua NAT. Điều này có nghĩa là câu trả lời quay trở lại thông qua ELB. Biểu đồ Amazon không chỉ ra mũi tên hướng lưu lượng ELB là hai chiều, tài liệu ELB cũng không nói rằng ELB hành xử như một NAT có trạng thái. Phải không?

Câu trả lời:


11

Các mũi tên trong sơ đồ chỉ cho biết hướng thiết lập kết nối - không phải luồng lưu lượng.

Có, lưu lượng truy cập trở lại thông qua ELB.

Nhưng, đó không phải là một NAT có trạng thái - đó là proxy kết nối TCP. Các máy ELB chấp nhận kết nối TCP trên các cổng nghe được định cấu hình, chấm dứt phiên SSL nếu được định cấu hình và thiết lập kết nối TCP mới đến máy chủ phụ trợ. Nếu trình nghe được cấu hình cho HTTP, ELB hoạt động ở chế độ phân tích nhận biết, ghi nhật ký và chuyển tiếp các yêu cầu HTTP đến back-end, nếu không, đó là thuyết không tải, thiết lập kết nối TCP mới 1: 1 cho back-end cho mỗi kết nối đến và "buộc các đường ống lại với nhau" (không có nhận thức hoặc sửa đổi ở mức HTTP).

Dù bằng cách nào, địa chỉ nguồn của kết nối đến ứng dụng của bạn sẽ là địa chỉ của nút ELB, không phải máy khách gốc. Đây là cách lưu lượng phản hồi trả về ELB để trả về máy khách.

Trong chế độ http, ELB thêm (hoặc gắn vào) X-Forwarded-Fortiêu đề để ứng dụng của bạn có thể xác định IP máy khách gốc, cũng như X-Forwarded-Proto: [ http | https ]để cho biết liệu kết nối máy khách có sử dụng SSL hay không và X-Forwarded-Portcho biết cổng giao diện người dùng.


Cập nhật: ở trên đề cập đến một loại cân bằng tải hiện được gọi là "ELB Classic" hoặc ELB / 1.0 (được tìm thấy trong chuỗi tác nhân người dùng mà nó gửi với kiểm tra sức khỏe HTTP).

Bộ cân bằng lớp 7 mới hơn, Bộ cân bằng tải ứng dụng hoặc ELB / 2.0 hoạt động tương tự, liên quan đến lưu lượng. Khả năng lớp 4 ("trong suốt" TCP) được loại bỏ khỏi ALB và các tính năng của lớp 7 được tăng cường đáng kể.

Loại cân bằng tải mới nhất, Bộ cân bằng tải mạng, là bộ cân bằng lớp 3. Không giống như hai cái kia, nó hoạt động rất giống NAT động, chỉ xử lý các kết nối bên trong (có nguồn gốc bên ngoài), ánh xạ cổng nguồn-addr + thông qua cổng EIP-addr + sang instance-private-ip: adde + port - với EIP bị ràng buộc với "bộ cân bằng" - và không giống như hai loại cân bằng khác, các trường hợp cần phải có trên các mạng con công cộng và sử dụng IP công khai của riêng chúng cho việc này.

Nói một cách khái niệm, Network Load Balancer dường như thực sự sửa đổi hành vi của Cổng Internet - chính là một đối tượng logic không thể bị vô hiệu hóa, thay thế hoặc gặp sự cố theo bất kỳ ý nghĩa nào. Điều này trái ngược với ELB và ALB, hoạt động thực sự trên các trường hợp EC2 "ẩn". NLB hoạt động trên cơ sở hạ tầng mạng, bởi tất cả các lần xuất hiện.


Cảm ơn. Bạn có thể giải thích về các chế độ nhận biết trọng tải, nhận biết trọng tải không? Ngoài ra, máy chủ web có thể biết liệu kết nối ban đầu có qua SSL không?
Ali

Tôi đã thêm một số thông tin bổ sung vào câu trả lời để giải quyết những điểm này.
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. Tôi rất vui khi đọc nó. Bạn có thể cung cấp một tài liệu tham khảo cho thông tin này?
Felipe Alvarez

1
@FelipeAlvarez, hóa ra bức tranh hoàn chỉnh phức tạp hơn nhiều. Mặc dù đây là cấu hình trực quan nhất, Network Load Balancer được tích hợp với cơ sở hạ tầng mạng thực tế theo cách nó thu được các luồng TCP (có thể thông qua các bảng trạng thái mạng) từ các thể hiện đích và có thể viết lại chúng và hoạt động như mong đợi ngay cả khi các trường hợp không được cấu hình theo cách này. Các thể hiện đích cần một tuyến mặc định được khai báo trong VPC - nó bị bỏ qua cho các gói trả về, nhưng vẫn phải có mặt. Sự vắng mặt của một tuyến đường mặc định tạo ra một lỗ đen.
Michael - sqlbot

1

Theo tài liệu AWS cho NLB, nó là lớp 4 chứ không phải lớp 3. Ngoài ra, máy chủ đích hoặc máy chủ đích không bắt buộc phải có trên mạng con công cộng. Vì thực tế, phạm vi địa chỉ IP của các nhóm mục tiêu phải là một trong những điều sau đây: Sau đây là các loại mục tiêu có thể:

dụ Các mục tiêu được chỉ định bởi ID cá thể.

ip Các mục tiêu được chỉ định bởi địa chỉ IP.

Khi loại mục tiêu là ip, bạn có thể chỉ định địa chỉ IP từ một trong các khối CIDR sau:

Các mạng con của VPC cho nhóm mục tiêu

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)

Quan trọng

Bạn không thể chỉ định địa chỉ IP có thể định tuyến công khai.

Tôi hi vọng cái này giúp được.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.