Phơi bày nhiều máy chủ phía sau NAT bằng một địa chỉ IP công cộng duy nhất

Đây là một câu hỏi Canonical về NAT và DNS

Tôi hiện đang cố gắng thiết lập một mạng với DMZ chứa máy chủ web và máy chủ email được phân tách khỏi Internet bằng tường lửa dịch địa chỉ mạng (NAT).

Tôi đã cài đặt tường lửa NAT với các giao diện sau:

WAN - x.x.x.x (redacted public IP address)
DMZ - 192.168.124.5/24
LAN - 192.168.123.5/24

Trên DMZ của tôi, tôi có hai máy chủ của mình:

Web server - 192.168.124.30
E-mail server - 192.168.124.32

Tôi biết rằng tôi sẽ cần định cấu hình DNS cho example.comtên miền để giải quyết cả hai example.comvà mail.example.comđến địa chỉ IP công cộng của tôi.

Tôi muốn tường lửa NAT của tôi chuyển tiếp tất cả các yêu cầu đến example.comtới máy chủ web ở 192.168.124.30 và tất cả các yêu cầu đến mail.example.comtới máy chủ email tại 192.168.124.32. Tôi thấy một tính năng "chuyển tiếp cổng" trong cấu hình tường lửa NAT của tôi nhưng dường như không thể đạt được những gì tôi đang tìm kiếm.

Bạn đang bị rối loạn trong suy nghĩ về cách thông tin chảy giữa các lớp của giao thức TCP / IP - cụ thể là giữa DNS và các giao thức lớp ứng dụng.

Bạn có một địa chỉ IP công cộng. DNS của bạn chắc chắn có thể giải quyết cả hai mail.example.comvà example.comđến cùng một địa chỉ IP công cộng.

Nói chung, các datagram IP chứa các yêu cầu đến địa chỉ IP công cộng của bạn, sẽ được nhận bởi giao diện bên ngoài của tường lửa của bạn, không chứa tên của máy chủ mà máy khách từ xa đang cố truy cập. Tường lửa của bạn không thể "biết" được tên máy chủ mà máy khách từ xa đã giải quyết, vì cả hai tên máy chủ đều phân giải cùng một địa chỉ IP. Lớp IP không biết tên máy chủ được sử dụng ở lớp ứng dụng.

Các giao thức TCP và UDP phân biệt các dịch vụ cụ thể được cung cấp bởi một máy chủ sử dụng số cổng. Trong trường hợp ví dụ của bạn, có thể sử dụng tính năng chuyển tiếp cổng (còn được gọi là dịch địa chỉ cổng hoặc tính năng PAT) của tường lửa NAT của bạn để gửi yêu cầu đến cổng TCP 80 (HTTP) đến máy chủ web trong khi gửi cổng TCP gửi đến 25 (SMTP) đến máy chủ email của bạn.

Tuy nhiên, nếu bạn có kế hoạch lưu trữ cùng một dịch vụ trên cả hai máy thì chiến lược này trở nên có vấn đề. Giả sử bạn sẽ lưu trữ cả một trang web an toàn trên máy chủ web của mình (để truy cập Khách hàng) và một trang web an toàn trên máy chủ email của bạn (đối với webmail). Yêu cầu đến địa chỉ IP công cộng của tường lửa NAT của bạn tới cổng TCP 443 (HTTPS) chỉ có thể được chuyển đến một máy chủ hoặc máy chủ khác.

Giải pháp tổng quát cho tình huống này là có nhiều địa chỉ IP công cộng hơn. Bởi vì địa chỉ IPv4 đang trở nên khan hiếm cũng có thể có vấn đề.

Chúng tôi cuối cùng làm việc xung quanh sự khan hiếm của các địa chỉ IP công cộng trong một số giao thức ở lớp ứng dụng. Ví dụ: HTTP / 1.1 đã thêm Host:tiêu đề cụ thể để cho phép máy chủ web lưu trữ nhiều trang web trên cùng một địa chỉ IP công cộng. TLS thêm tiện ích mở rộng Chỉ định tên máy chủ (SNI) để cho phép lựa chọn chứng chỉ phù hợp dựa trên tên máy chủ được nhập bởi máy khách từ xa.

Thực hiện loại giải pháp này trong lớp ứng dụng có nghĩa là mọi giao thức của lớp ứng dụng sẽ cần "sửa chữa" riêng của nó (và sau đó tất cả các phần mềm máy chủ và máy khách sẽ phải thực hiện "sửa lỗi" đó). Đó là một trật tự cao.

Thay vì sửa đổi giao thức lớp ứng dụng, một số giao thức có thể dễ dàng được "ghép" giữa nhiều máy chủ bằng phần mềm có thể "định tuyến" các yêu cầu. Điều này có khả năng vượt xa những gì một tường lửa NAT đơn giản có khả năng vì các gói cần phải được kiểm tra ở lớp ứng dụng. Sử dụng proxy ngược như nginx là một ví dụ điển hình của loại "ghép kênh" này (hoặc quy tắc xuất bản Web trên Forefront TMG hoặc Máy chủ ISA trong môi trường Microsoft) cho giao thức HTTP. Về lý thuyết, bất kỳ giao thức nào cũng có thể được ghép kênh thông qua một proxy ngược nhưng giao thức càng bí truyền thì bạn càng có khả năng nói về việc có mã tùy chỉnh được viết.

Khi bạn cần cung cấp cùng một dịch vụ từ hai máy chủ khác nhau trên một địa chỉ IP công cộng duy nhất, bạn luôn có tùy chọn để di chuyển một trong các máy chủ sang một cổng không chuẩn. Tuy nhiên, điều này sẽ yêu cầu khách hàng biết về cổng không chuẩn. Trong trường hợp HTTP (S), điều này dẫn đến các URL có http://example.com:XXXký hiệu (trong đó XXXlà số cổng không chuẩn). Cho dù điều này sẽ có vấn đề trong tình huống của bạn là điều mà chỉ bạn mới có thể quyết định. (Kinh nghiệm của tôi đã chỉ ra rằng hầu như không có người dùng cuối nào có khả năng xử lý :XXXký hiệu cổng trong bất kỳ URL nào họ phải nhập bằng tay.)

Tính năng "Chuyển tiếp cổng" của bạn có thể cho phép bạn gửi lưu lượng truy cập cho: 80 và: 443 đến 192.168.124.30 và các cổng còn lại (hoặc chỉ những máy chủ email của bạn được định cấu hình để sử dụng) đến 192.168.124.32. Nếu vì một lý do nào đó, bạn cần một trong hai cổng đó cho máy chủ email cũng như cho máy chủ web, thì bạn đang gặp rắc rối. Để phương pháp này hoạt động, mọi truy cập web vào máy chủ email của bạn sẽ phải ở một cổng khác (rất có thể là không chuẩn). Có lẽ bạn cũng sẽ thiết lập máy chủ web để chuyển hướng bất cứ thứ gì nói " mail.example.com" để sử dụng thay thế, cho những người dùng không biết cách nối số cổng và / hoặc chỉ định kết nối an toàn. (Bạn được sẽ sử dụng kết nối web chỉ an toàn cho các máy chủ mail, phải không?)https://mail.example.com:other_port

Đây là ở tầng Giao vận chứ không phải lớp Ứng dụng, có nghĩa là nó không phải dựa vào kiểm tra gói sâu. Thay vào đó, nó có thể nhìn vào một vị trí dễ tìm trong tiêu đề TCP cho cổng.

Nếu "yêu cầu đến" của bạn là những thứ khác nhau, tức là lưu lượng truy cập web (HTTP) cho máy chủ web và lưu lượng thư (SMTP) cho máy chủ thư, thì điều này thực sự có thể được thực hiện: HTTP sử dụng cổng TCP 80 (443 cho HTTPS), trong khi SMTP sử dụng cổng TCP 25; do đó, từ cùng một địa chỉ IP công cộng, bạn có thể chuyển tiếp lưu lượng HTTP đến máy chủ web của mình và lưu lượng SMTP đến máy chủ thư của bạn; đây là "cổng chuyển tiếp" nghĩa là gì. Bất kỳ tường lửa phong nha có khả năng này.

Tuy nhiên, nếu tình cờ hai máy chủ cần có thể chấp nhận loại lưu lượng CÙNG, nếu máy chủ thư của bạn cũng lưu trữ dịch vụ webmail, thì bạn sẽ gặp rắc rối, vì bạn có thể chuyển tiếp các cổng cụ thể (80 và / hoặc 443) chỉ đến một máy chủ duy nhất; để phân tách lưu lượng truy cập web dựa trên tên mà máy khách đã sử dụng để yêu cầu nó, bạn cần một cái gì đó hoạt động ở mức cao hơn TCP / IP, chẳng hạn như proxy ngược.