Предоставление нескольких серверов за NAT с использованием одного публичного IP-адреса

Это канонический вопрос о NAT и DNS

В настоящее время я пытаюсь настроить сеть с DMZ, содержащей веб-сервер и почтовый сервер, отделенные от Интернета брандмауэром преобразования сетевых адресов (NAT).

Я установил брандмауэр NAT со следующими интерфейсами:

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

На моей DMZ у меня есть два хозяина:

Web server - 192.168.124.30
E-mail server - 192.168.124.32

Я знаю, что мне нужно будет настроить DNS для example.comдомена, чтобы разрешить example.comи mail.example.comмой публичный IP-адрес.

Я хотел бы, чтобы мой брандмауэр NAT перенаправлял все входящие запросы example.comна веб-сервер в 192.168.124.30, а все входящие запросы mail.example.com- на почтовый сервер в 192.168.124.32. Я вижу функцию «переадресация портов» в конфигурации моего брандмауэра NAT, но не могу достичь того, что ищу.

Вы запутались в своих мыслях о том, как информация передается между уровнями стека протоколов TCP / IP, в частности между DNS и протоколами прикладного уровня.

У вас есть один публичный IP-адрес. Ваш DNS может разрешить оба mail.example.comи один и example.comтот же публичный IP-адрес.

Как правило, дейтаграммы IP, содержащие запросы на ваш общедоступный IP-адрес, которые будут получены внешним интерфейсом брандмауэра, не содержат имя хоста, к которому пытается получить доступ удаленный клиент. Ваш брандмауэр не может волшебным образом «знать», какое имя хоста разрешено удаленным клиентом, поскольку оба имени хоста разрешаются на один и тот же IP-адрес. Уровень IP не знает имя хоста, используемое на уровне приложения.

Протоколы TCP и UDP различают определенные услуги, предлагаемые хостом, используя номера портов. В вашем примере может быть возможно использовать функцию переадресации портов (также называемую трансляцией адреса порта или PAT) вашего межсетевого экрана NAT для отправки входящих запросов на порт TCP 80 (HTTP) на веб-сервер при отправке входящего порта TCP 25 (SMTP) на ваш почтовый сервер.

Однако, если вы планируете разместить одну и ту же службу на обеих машинах, эта стратегия становится проблематичной. Предположим, вы собираетесь разместить на своем веб-сервере как защищенный веб-сайт (для доступа клиентов), так и защищенный веб-сайт на сервере электронной почты (для веб-почты). Запросы, поступающие на общедоступный IP-адрес брандмауэра NAT на порт TCP 443 (HTTPS), могут направляться только на один сервер или другой.

Обобщенное решение этой ситуации - иметь больше публичных IP-адресов. Поскольку IPv4-адресов становится мало, это также может быть проблематично.

В итоге мы работаем над нехваткой публичных IP-адресов в некоторых протоколах на уровне приложений. Например, HTTP / 1.1 специально добавил Host:заголовок, чтобы веб-сервер мог размещать несколько веб-сайтов на одном и том же общедоступном IP-адресе. TLS добавляет расширение Server Name Indication (SNI) для разрешения выбора соответствующего сертификата на основе имени хоста, введенного удаленным клиентом.

Выполнение такого рода обходного пути на уровне приложений означает, что каждому протоколу уровня приложений потребуется свое собственное «исправление» (и тогда все серверное и клиентское программное обеспечение должно будет реализовать это «исправление»). Это высокий заказ.

Вместо изменения протокола прикладного уровня некоторые протоколы легко поддаются «мультиплексированию» между несколькими хостами с использованием программного обеспечения, которое может «маршрутизировать» запросы. Скорее всего, это выходит за рамки возможностей простого брандмауэра NAT, поскольку пакеты необходимо проверять на уровне приложений. Использование обратного прокси-сервера, такого как nginx, является хорошим примером такого рода «мультиплексирования» (или правил веб-публикации на Forefront TMG или ISA Server в среде Microsoft) для протокола HTTP. Теоретически любой протокол может быть мультиплексирован через обратный прокси-сервер, но чем более эзотерическим является протокол, тем больше вероятность того, что вы будете говорить о написании собственного кода.

Когда вам нужно предложить одну и ту же услугу от двух разных хостов на одном общедоступном IP-адресе, у вас всегда есть возможность переместить один из хостов на нестандартный порт. Однако для этого потребуется, чтобы клиенты знали о нестандартном порте. В случае HTTP (S) это приводит к URL-адресам с http://example.com:XXXобозначением (где XXXнестандартный номер порта). Будет ли это проблематичным в вашей ситуации - решать только вы. (Мой опыт показал, что практически ни один из конечных пользователей не способен обрабатывать :XXXобозначения портов в любом URL-адресе, который они должны вводить вручную.)

Ваша функция «Переадресация портов» может позволить вам отправлять трафик, предназначенный для: 80 и: от 443 до 192.168.124.30, а остальные порты (или только те, которые настроены для использования вашим почтовым сервером) на 192.168.124.32. Если по какой-либо причине вам нужен любой из этих двух портов для сервера электронной почты, а также для веб-сервера, у вас возникли проблемы. Чтобы этот метод работал, любой веб-доступ к вашему почтовому серверу должен быть на другом (скорее всего нестандартном) порту. Возможно, вы также настроили бы веб-сервер для перенаправления всего, что говорит " mail.example.com", чтобы использовать вместо пользователей, которые не знают, как добавить номер порта и / или указать безопасное соединение. (Вы которые собираетесь использовать только безопасные веб - соединение с почтовым сервером, не так ли?)https://mail.example.com:other_port

Это на транспортном уровне, а не на прикладном уровне, что означает, что он не должен полагаться на глубокую проверку пакетов. Вместо этого он может посмотреть на легко найти местоположение в заголовке TCP для порта.

Если ваши «входящие запросы» - это разные вещи, например, веб-трафик (HTTP) для веб-сервера и почтовый трафик (SMTP) для почтового сервера, это действительно можно сделать: HTTP использует порт 80 (443 для HTTPS), в то время как SMTP использует TCP-порт 25; таким образом, с одного и того же публичного IP-адреса вы можете перенаправлять HTTP-трафик на ваш веб-сервер и SMTP-трафик на ваш почтовый сервер; это то, что означает «переадресация портов». Любой приличный брандмауэр способен на это.

Однако если случайно два сервера должны быть в состоянии принимать тот же тип трафика, например, если на вашем почтовом сервере также размещена служба веб-почты, у вас возникнут проблемы, поскольку вы можете перенаправлять определенные порты (80 и / или 443) только на один сервер; Чтобы разделить веб-трафик на основе имени, которое клиент использовал для запроса, вам нужно что-то, работающее на более высоком уровне, чем TCP / IP, например обратный прокси-сервер.