Вы запутались в своих мыслях о том, как информация передается между уровнями стека протоколов 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-адресе, который они должны вводить вручную.)