Викриття декількох серверів позаду 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 для надсилання вхідних запитів на порт 80 TCP (HTTP) на веб-сервер під час надсилання вхідного порту TCP 25 (SMTP) на ваш сервер електронної пошти.

Якщо ж ви плануєте розміщувати одну і ту ж послугу на обох машинах, тоді ця стратегія стає проблематичною. Припустимо, ви збираєтеся розмістити як захищений веб-сайт на своєму веб-сервері (для доступу клієнта), так і захищений веб-сайт на своєму сервері електронної пошти (для веб-пошти). Запити, що надходять на загальнодоступну IP-адресу вашого брандмауера до порту 443 TCP (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:other_port

Це на транспортному шарі, а не на рівні програми, а значить, не потрібно покладатися на глибоку перевірку пакетів. Натомість він може шукати місце, яке легко знайти у заголовку TCP для порту.

Якщо ваші "вхідні запити" відрізняються, тобто веб-трафік (HTTP) для веб-сервера та поштовий трафік (SMTP) для поштового сервера, це дійсно можна зробити: HTTP використовує порт TCP 80 (443 для HTTPS), а SMTP використовує порт 25 TCP; таким чином, з тієї ж загальнодоступної IP-адреси ви можете пересилати трафік HTTP на ваш веб-сервер, а SMTP-трафік на ваш поштовий сервер; ось що означає "переадресація порту". На це здатний будь-який гідний брандмауер.

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