Zagubiłeś się w myśleniu o tym, jak informacje przepływają między warstwami stosu protokołów TCP / IP - w szczególności między DNS a protokołami warstwy aplikacji.
Masz jeden publiczny adres IP. Twój DNS pewnością może rozwiązać oba mail.example.comi example.comdo tego samego publicznego adresu IP.
Zasadniczo datagramy IP zawierające żądania na twój publiczny adres IP, które będą odbierane przez zewnętrzny interfejs zapory, nie zawierają nazwy hosta, do którego próbuje uzyskać dostęp klient zdalny. Zapora nie może magicznie „wiedzieć”, którą nazwę hosta rozpoznał klient zdalny, ponieważ obie nazwy hostów są przetwarzane na ten sam adres IP. Warstwa IP nie zna nazwy hosta używanej w warstwie aplikacji.
Protokoły TCP i UDP różnicują określone usługi oferowane przez hosta za pomocą numerów portów. W twoim przykładzie może być możliwe użycie funkcji przekierowania portów (zwanej także translacją adresów portów lub PAT) zapory NAT do wysyłania przychodzących żądań do portu TCP 80 (HTTP) do serwera WWW podczas wysyłania przychodzącego portu TCP 25 (SMTP) na twój serwer e-mail.
Jeśli jednak planujesz hostować tę samą usługę na obu komputerach, ta strategia staje się problematyczna. Załóżmy, że będziesz hostować zarówno bezpieczną stronę internetową na swoim serwerze internetowym (w celu uzyskania dostępu klienta), jak i bezpieczną stronę internetową na swoim serwerze e-mailowym (dla poczty internetowej). Żądania przychodzące na publiczny adres IP zapory NAT do portu TCP 443 (HTTPS) mogą być kierowane tylko do jednego serwera lub drugiego.
Uogólnionym rozwiązaniem tej sytuacji jest posiadanie większej liczby publicznych adresów IP. Ponieważ adresów IPv4 jest coraz mniej, może to również stanowić problem.
Ostatecznie pracujemy nad niedoborem publicznych adresów IP w niektórych protokołach w warstwie aplikacji. Na przykład HTTP / 1.1 dodał Host:nagłówek, aby umożliwić serwerowi hostingowemu wiele witryn pod tym samym publicznym adresem IP. TLS dodaje rozszerzenie SNI ( Server Name Indication ), aby umożliwić wybór odpowiedniego certyfikatu na podstawie nazwy hosta wprowadzonej przez klienta zdalnego.
Wykonanie tego rodzaju obejścia w warstwie aplikacji oznacza, że każdy protokół warstwy aplikacji potrzebowałby własnej „poprawki” (a następnie całe oprogramowanie serwera i klienta musiałoby wdrożyć tę „poprawkę”). To wysokie zamówienie.
Zamiast modyfikować protokół warstwy aplikacji, niektóre protokoły łatwo poddają się „multipleksowaniu” między wieloma hostami za pomocą oprogramowania, które może „trasować” żądania. Prawdopodobnie wykracza to poza możliwości zwykłej zapory NAT, ponieważ pakiety muszą być sprawdzane w warstwie aplikacji. Korzystanie z odwrotnego proxy, takiego jak nginx, jest dobrym przykładem tego rodzaju „multipleksowania” (lub reguł publikowania w Internecie na Forefront TMG lub ISA Server w środowisku Microsoft) dla protokołu HTTP. Teoretycznie każdy protokół może być multipleksowany przez odwrotny serwer proxy, ale im bardziej ezoteryczny jest protokół, tym większe prawdopodobieństwo, że będziesz mówić o napisaniu niestandardowego kodu.
Gdy musisz zaoferować tę samą usługę z dwóch różnych hostów na jednym publicznym adresie IP, zawsze masz możliwość przeniesienia jednego z hostów na niestandardowy port. Będzie to jednak wymagać, aby klienci wiedzieli o niestandardowym porcie. W przypadku HTTP (S) powoduje to powstanie adresów URL z http://example.com:XXXzapisem (gdzie XXXjest niestandardowy numer portu). To, czy byłoby to problematyczne w twojej sytuacji, zależy od Ciebie. (Z mojego doświadczenia wynika, że praktycznie żaden użytkownik końcowy nie jest w stanie obsłużyć :XXXnotacji portu w żadnym adresie URL, który musi podać ręcznie).