Ujawnianie wielu serwerów za NAT przy użyciu jednego publicznego adresu IP

To jest kanoniczne pytanie dotyczące NAT i DNS

Obecnie próbuję skonfigurować sieć z DMZ zawierającą serwer WWW i serwer poczty elektronicznej oddzielone od Internetu zaporą translacji adresów sieciowych (NAT).

Zainstalowałem zaporę NAT z następującymi interfejsami:

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

W mojej strefie DMZ mam dwóch hostów:

Web server - 192.168.124.30
E-mail server - 192.168.124.32

Wiem, że będę musiał skonfigurować DNS dla example.comdomeny, aby rozpoznawał zarówno mój, jak example.comi mail.example.commój publiczny adres IP.

Chciałbym, aby moja zapora NAT przekazała wszystkie przychodzące żądania do example.comserwera WWW pod adresem 192.168.124.30, a wszystkie przychodzące żądania do mail.example.comserwera poczty e-mail pod adresem 192.168.124.32. Widzę funkcję „przekierowywania portów” w konfiguracji zapory NAT, ale wydaje się, że nie mogę osiągnąć tego, czego szukam.

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).

Funkcja „Przekazywanie portów” może umożliwić wysyłanie ruchu przeznaczonego dla: 80 i: od 443 do 192.168.124.30 i pozostałych portów (lub tylko tych, dla których skonfigurowany jest serwer e-mail) do 192.168.124.32. Jeśli z jakiegoś powodu potrzebujesz jednego z tych dwóch portów dla serwera e-mail, a także dla serwera WWW, masz kłopoty. Aby ta metoda zadziałała, każdy dostęp internetowy do twojego serwera e-mail musiałby być na innym (najprawdopodobniej niestandardowym) porcie. Prawdopodobnie skonfigurowałbyś również serwer WWW, aby przekierowywał wszystko, co mówi „ mail.example.com”, aby użyć , dla użytkowników, którzy nie wiedzą, jak dołączyć numer portu i / lub określić bezpieczne połączenie. (Ty są zamiar używać tylko bezpiecznych połączeń internetowych na serwerze pocztowym, prawda?)https://mail.example.com:other_port

Jest to warstwa transportowa, a nie warstwa aplikacyjna, co oznacza, że ​​nie musi polegać na głębokiej inspekcji pakietów. Zamiast tego może spojrzeć na łatwą do znalezienia lokalizację w nagłówku TCP portu.

Jeśli „przychodzące żądania” są różne, np. Ruch internetowy (HTTP) dla serwera internetowego i ruch pocztowy (SMTP) dla serwera pocztowego, można to rzeczywiście zrobić: HTTP używa portu TCP 80 (443 dla HTTPS), podczas gdy SMTP używa portu TCP 25; w ten sposób z tego samego publicznego adresu IP można przesyłać ruch HTTP do serwera WWW, a ruch SMTP do serwera poczty; to właśnie oznacza „przekierowanie portów”. Każda przyzwoita zapora jest w stanie to zrobić.

Jeśli jednak przypadkiem oba serwery muszą być w stanie zaakceptować taki sam ruch, np. Jeśli Twój serwer pocztowy obsługuje również usługę poczty internetowej, masz kłopoty, ponieważ możesz przekierować określone porty (80 i / lub 443) tylko do jednego serwera; Aby oddzielić ruch internetowy na podstawie nazwy, której używał klient, potrzebujesz czegoś działającego na wyższym poziomie niż TCP / IP, takiego jak odwrotne proxy.