Điểm:0

Proxy gửi đi sử dụng nhiều địa chỉ IP công khai trên EC2

lá cờ br

Chúng tôi có một loạt máy chủ phụ trợ ở dạng phiên bản EC2 dựa trên mạng con riêng trong AWS VPC cần kết nối với API của bên thứ ba. API này đang giới hạn các yêu cầu mà chúng tôi có thể gửi dựa trên địa chỉ IP ban đầu và trong khi mở rộng quy mô thiết lập của mình, chúng tôi đã bắt đầu đạt đến giới hạn đối với IP của cổng NAT được sử dụng cho tất cả lưu lượng truy cập ra bên ngoài.

Vì vậy, tôi muốn thiết lập proxy cho lưu lượng truy cập bên ngoài với một số EIP được đính kèm. Để thử nghiệm, tôi hiện đang sử dụng phiên bản Amazon Linux 2 có 2 ENI và mỗi ENI được đính kèm 2 EIP.Các máy chủ phụ trợ mở một đường hầm SSH tới proxy gửi đi và ánh xạ API của bên thứ 3 tới một cổng cục bộ, một mục nhập trong tệp lưu trữ của máy chủ sẽ chuyển hướng tất cả lưu lượng truy cập đến tên máy chủ đó sang localhost và thiết lập này nói chung hoạt động tốt nhưng lưu lượng truy cập ra ngoài từ proxy luôn chỉ sử dụng EIP được liên kết đầu tiên.

Vì vậy, thiết lập của tôi trông như thế này:

ENI1: eth0
IP1 riêng tư: 10.0.11.81
IP2 riêng: 10.0.11.82

ENI2: eth1
IP3 riêng: 10.0.11.52
IP4 riêng tư: 10.0.11.53

bảng lộ trình ban đầu:
mặc định qua 10.0.11.1 dev eth0
mặc định qua 10.0.11.1 dev eth1 số liệu 10001
10.0.11.0/24 dev eth0 liên kết phạm vi kernel proto src 10.0.11.81
10.0.11.0/24 dev eth1 liên kết phạm vi kernel proto src 10.0.11.52
169.254.169.254 nhà phát triển eth0

Bây giờ tôi muốn có thể chỉ định máy chủ phụ trợ nào sử dụng EIP nào khi gọi API qua proxy gửi đi. Lần thử đầu tiên của tôi là như sau:

  • thiết lập 4 người dùng khác nhau trên máy chủ proxy
  • thêm quy tắc iptable cho mỗi người dùng như vậy: iptables -t nat -m owner --uid-owner user1 -A POSTROUTING -j SNAT --to IP1 vân vân.
  • điều này hoạt động đối với 2 IP được gắn với ENI chính (tức là eth0 trong máy) nhưng không hoạt động đối với 2 IP được liên kết với ENI thứ hai (eth1)
  • thêm -o eth1 đến tuyên bố cũng không hoạt động

Lần thử tiếp theo của tôi là tạo các bảng định tuyến tùy chỉnh cho từng địa chỉ IP và khớp chúng với các quy tắc chính sách:

  • tạo bảng định tuyến tùy chỉnh, tức là cho IP3:
mặc định qua 10.0.11.1 dev eth1
10.0.11.0/24 dev eth1 liên kết phạm vi tĩnh proto src 10.0.11.52
Liên kết phạm vi 169.254.169.254 dev eth1
  • tạo quy tắc iptables để đánh dấu lưu lượng bắt nguồn từ user3: -A OUTPUT -m chủ sở hữu --uid-chủ sở hữu 1003 -j MARK --set-xmark 0x3/0xffffffff
  • tạo quy tắc để sử dụng bảng định tuyến tùy chỉnh cho tất cả các gói được đánh dấu 3: 32763: từ tất cả tra cứu fwmark 0x3 ip3
  • điều này một lần nữa không hoạt động. các gói được xử lý khác nhau. tất cả người dùng có thể giao tiếp với thế giới ngoại trừ người dùng 3 trong ví dụ trên.

Tôi đang làm gì sai? Có điều gì đó tầm thường mà tôi đang thiếu hay toàn bộ cách tiếp cận của tôi sẽ thất bại? Tôi rất cởi mở với các đề xuất, cả về cách thiết lập này hoạt động cũng như các phương pháp thay thế...

Cảm ơn rất nhiều trước!

Tim avatar
lá cờ gp
Tim
Một điểm dừng đơn giản hơn sẽ là một cổng NAT cho mỗi mạng con/AZ, với định tuyến được thiết lập phù hợp. Phiên bản NAT thay vì cổng NAT sẽ rẻ hơn nhưng yêu cầu thiết lập/bảo trì nhiều hơn. Tuy nhiên, câu trả lời của John có lẽ là tốt nhất, hãy tăng giới hạn.
lá cờ br
Proxy gửi đi là điểm dừng của tôi. Việc tổ chức lại các mạng con, di chuyển máy chủ xung quanh, v.v. sẽ tốn nhiều công sức hơn là chỉ chuyển hướng một phần lưu lượng truy cập ra bên ngoài thông qua đường hầm SSH. Điều đó có thể được thực hiện đối với các máy hiện có với tác động tối thiểu đến kiến ​​trúc và không có thời gian chết.
Điểm:3
lá cờ cn

Liên hệ với tổ chức đang chạy API và giải thích tình huống. Tạo mối quan hệ kinh doanh là một khởi đầu tốt để giải quyết vấn đề.

Triển khai IPv6 để giảm độ phức tạp kỹ thuật. AWS sẽ cung cấp cho bạn /64 trên mỗi mạng con của không gian công cộng, cho phép giao tiếp trực tiếp giữa các phiên bản của bạn và API. Địa chỉ duy nhất cho mỗi phiên bản cho thấy rõ ràng bạn thực sự đang mở rộng quy mô. Việc yêu cầu mạng của bạn được phép có hạn ngạch cao hơn sẽ trở nên dễ dàng hơn, vì tất cả đều nằm trong /56 của VPC của bạn.

lá cờ br
Cảm ơn! Tăng giới hạn thực sự sẽ là một lựa chọn mà tôi chưa xem xét. Thật không may, IPv6 không được họ hỗ trợ, nếu không thì đó sẽ là lựa chọn đầu tiên của tôi. Tôi đã cân nhắc việc phân đoạn mạng con hơn nữa để có thể thêm nhiều cổng NAT hơn và phân bổ tải hoặc thậm chí di chuyển tất cả các máy chủ phụ trợ vào một mạng con công cộng để có thể gán trực tiếp các EIP riêng lẻ cho chúng. Nhưng tôi muốn tránh di chuyển các máy chủ phụ trợ có quyền truy cập cơ sở dữ liệu vào một mạng con công cộng và việc phân chia lại thiết lập hiện tại cũng là một nỗ lực đáng kể. Proxy gửi đi có vẻ như là một giải pháp tạm thời tốt.
Điểm:0
lá cờ br

Rốt cuộc, tôi đã tự mình tìm ra giải pháp và ghi lại nó ở đây: Cách tốt nhất để định tuyến lưu lượng dựa trên người dùng đã đăng nhập thông qua tuyến dự phòng cụ thể?

Chỉ trong trường hợp smeone vấp phải điều này trong tương lai.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.