Elastic IP của EC2 không phải là địa chỉ VPN riêng của instance

Instance có một địa chỉ riêng, Elastic IP được liên kết với nó, và một tuyến cho /32 công khai đó được thêm vào VPN với hy vọng hai thứ sẽ trở thành một. Chúng không như vậy. Elastic IP là một phép dịch được thực hiện bên ngoài khách, bởi cổng internet, trên lưu lượng đi theo đường internet. Hệ điều hành của khách không bao giờ thấy địa chỉ đó được cấu hình trên một giao diện. Thêm nó vào giao diện đường hầm không tái tạo phép dịch thượng nguồn và tạo ra một danh tính thứ hai, xung đột cho cùng một máy.

Hai địa chỉ, một instance

Giao diện mạng của instance giữ một địa chỉ riêng bên trong VPC, và đó là địa chỉ mà khách biết. Elastic IP được liên kết với cùng giao diện nhưng sống ở phía công khai của ánh xạ.

Mọi thứ đến được instance qua internet đều đến dưới dạng đã được dịch sang địa chỉ riêng. Mọi thứ instance gửi ra internet đều đi ra với Elastic IP là nguồn, một lần nữa vì phép dịch đó.

Bên trong khách chỉ tồn tại một địa chỉ. Bên ngoài tồn tại hai. Sự bất đối xứng đó giải thích phần lớn sự nhầm lẫn trong lĩnh vực này. Khách không thể cấu hình thứ mà cổng dịch. Nó chỉ có thể trả lời trên địa chỉ mà nó thực sự có.

Cổng internet thực sự làm gì

Tài liệu của AWS về cổng internet mô tả cách sắp xếp: instance biết địa chỉ IPv4 riêng của mình, và cổng cung cấp phép dịch tương ứng sang IPv4 công khai hoặc Elastic IP cho lưu lượng trên đường internet.

Đó là dịch địa chỉ mạng, không phải bí danh. Ánh xạ do cổng duy trì, gắn với liên kết và chỉ áp dụng cho các gói đi qua nó. Bỏ liên kết đi và danh tính công khai biến mất mà khách không hề hay biết.

Vì vậy một gói VPN riêng được gửi tới /32 công khai không bị diễn giải lại thành gói riêng tới địa chỉ cục bộ của khách. Gói đi theo tuyến mà nó khớp, tuyến này gửi nó tới cổng internet, và hành vi của cổng phụ thuộc vào việc đường đi có được cho phép theo cả hai chiều hay không.

Tại sao mánh giao diện đường hầm thất bại

Gán Elastic IP cho một giao diện đường hầm đòi hỏi khách phải coi một địa chỉ công khai là cục bộ. Giờ hai thứ cùng đòi một địa chỉ: phép dịch của cổng trên đường internet và giao diện cục bộ bên trong đường hầm. Lưu lượng quay về không có câu trả lời nhất quán về việc cái nào áp dụng.

Ngay cả khi có vẻ hoạt động, thiết kế đã giấu đi câu hỏi thật. Các máy khách hoặc đến địa chỉ riêng qua đường hầm hoặc đến điểm cuối công khai qua internet, và hai đường này có nhóm bảo mật khác nhau, ghi nhật ký khác nhau và chế độ hỏng khác nhau.

Địa chỉ chưa bao giờ là vấn đề. Việc chọn đường mới là vấn đề.

Ba mục tiêu, ba thiết kế

Nếu mục tiêu là một điểm cuối VPN công khai, Elastic IP là công cụ đúng: các peer từ xa kết nối tới nó qua internet và vận chuyển được mã hóa kết thúc trên instance. Lưu lượng ứng dụng bên trong sau đó dùng địa chỉ riêng.

Nếu mục tiêu là truy cập riêng tới ứng dụng, đích là địa chỉ riêng hoặc một tên DNS riêng phân giải tới đó, và tuyến VPN, nhóm bảo mật cùng đường quay về đều phải khớp. Elastic IP hoàn toàn không xuất hiện trong thiết kế đó.

Nếu mục tiêu là một danh tính ra công khai ổn định cho người dùng VPN, đó là thiết kế NAT ở phía ra, không phải một địa chỉ trên đường hầm của máy khách. Ba mục tiêu nghe giống nhau tạo ra ba sơ đồ khác nhau, và chỉ một trong số đó liên quan đến việc đặt Elastic IP ở một vị trí mới.

Xác minh đường bạn đã chọn

Với truy cập riêng, hãy xác nhận tuyến VPN bao phủ tiền tố riêng, bảng tuyến của VPC trả lưu lượng về đường hầm, nhóm bảo mật cho phép nguồn của máy khách và tường lửa của chính máy khách cho phép câu trả lời. Sau đó thử một yêu cầu thật thay vì ping.

Với truy cập công khai, hãy xác nhận lối ra internet của máy khách, định tuyến của lối vào công khai và chính sách bảo mật của nó. Việc máy khách VPN có thể đến một điểm cuối công khai qua đường hầm hay không phụ thuộc vào quy tắc ra và tường lửa của đường hầm, không phải vào liên kết Elastic IP.

Nếu một tên máy chủ công khai phải hoạt động từ cả hai phía, hãy dùng thiết kế DNS trả lời bằng địa chỉ riêng cho máy khách VPN và địa chỉ công khai cho mọi người khác, và giữ chứng chỉ hợp lệ cho tên chứ không phải cho địa chỉ. Thứ tự công việc: đặt tên cho mục tiêu, chọn địa chỉ thuộc về nó, rồi xác minh tuyến, chính sách và một yêu cầu.