Это Канонический вопрос про NAT и DNS
В настоящее время я пытаюсь настроить сеть с демилитаризованной зоной, содержащей веб-сервер и сервер электронной почты, отделенные от Интернета межсетевым экраном преобразования сетевых адресов (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 добавляет Индикация имени сервера (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:другой_порт вместо этого для пользователей, которые не знают, как добавить номер порта и / или указать безопасное соединение. (Вы являются собираетесь использовать только безопасные веб-соединения с почтовым сервером, верно?)
Это на транспортном уровне, а не на прикладном уровне, что означает, что он не должен полагаться на глубокую проверку пакетов. Вместо этого он может найти удобное для поиска место в заголовке TCP для порта.
Если ваши «входящие запросы» - это разные вещи, то есть веб-трафик (HTTP) для веб-сервера и почтовый трафик (SMTP) для почтового сервера, это действительно возможно: HTTP использует TCP-порт 80 (443 для HTTPS), а SMTP использует TCP-порт 25; таким образом, с одного и того же общедоступного IP-адреса вы можете пересылать HTTP-трафик на свой веб-сервер и SMTP-трафик на свой почтовый сервер; вот что означает «перенаправление портов». На это способен любой достойный межсетевой экран.
Однако, если случайно два сервера должны иметь возможность принимать ОДИН тип трафика, например. если на вашем почтовом сервере также есть служба веб-почты, у вас проблемы, потому что вы можете перенаправить определенные порты (80 и / или 443) только на один сервер; чтобы разделить веб-трафик на основе имени, которое клиент использовал для его запроса, вам нужно что-то, работающее на более высоком уровне, чем TCP / IP, например обратный прокси.