Назад | Перейти на главную страницу

Подсеть DMZ: в NAT или нет?

Я собираюсь настроить DMZ за Cisco ASA, которая будет содержать большое количество внешних балансировщиков нагрузки HTTP и служб разгрузки SSL - более 100 IP-адресов, сосредоточенных на меньшем количестве хостов.

Раньше я держал все хосты на частных IP-адресах RFC1918 и добавлял статические сопоставления (IP-by-IP) для каждой службы, которую я обычно выставляю в DMZ. Это стало раздражающим, так как мы начали добавлять дополнительные IP-адреса DMZ с достаточно высокой скоростью, поэтому становится утомительно настраивать каждый из них индивидуально. Я хотел бы изменить его так, чтобы вся подсеть DMZ была настроена так, чтобы разрешать HTTP и HTTPS извне -> dmz, чтобы балансировщики нагрузки могли просто захватывать новые IP-адреса по мере необходимости, не обновляя конфигурацию ASA каждый раз.

Теперь мне интересно, имеет ли смысл иметь DMZ в подсети RFC1918 и использовать статический NAT для всей подсети, или я должен просто позволить DMZ быть моим распределением внешних IP-адресов напрямую и полагаться исключительно на списки доступа и исключение NAT / NAT для идентификации.

Некоторые грубые изображения ASCII:

Example using direct outside IP addresses:
  Internet  ---> ASA ---> Internal (10.1.0.0/16)
                  |
                  +-----> DMZ (1.2.3.0/24)

Example using NATed IP addresses:
  Internet  ---> ASA ---> Internal (10.1.0.0/16)
                  |
     (1.2.3.0/24) +-----> DMZ (10.99.0.0/24)

Преимущество, которое я вижу в использовании адреса с NAT, - это переносимость - мне не нужно перенумеровать внутреннюю DMZ, если мой вышестоящий провайдер и распределение меняются. Обратной стороной является сложность - теперь мне приходится иметь дело с внутренними IP-адресами и внешними IP-адресами в моей собственной сети и т. Д. По вашему опыту, какая установка работает лучше?

Есть причины пойти в любом направлении, о котором говорили вы и другие.

Наличие слоя (своего рода каламбура) абстракции в виде статического NAT 1: 1 - это неплохо, поскольку вам, вероятно, не придется перенумеровать внутренние хосты, если ваш IP-блок WAN изменится. Однако сложности и нюансы, которые NAT вносит в поток пакетов через ASA, могут быть проблематичными по сравнению с простой маршрутизацией и проверками ACL.

Моя личная точка зрения такова, что NAT здесь, чтобы остаться с IPv4. Что касается стеков IPv4 на хостах, у меня нет проблем со статическим NAT на восходящем межсетевом экране. Однако для стеков IPv6 на хостах NAT отсутствует. На ASA IPv4 и IPv6 могут работать бок о бок с NAT для IPv4 и традиционной маршрутизацией для IPv6.

Есть еще одна причина, по которой вы можете захотеть использовать статический NAT, и она связана с ростом. ASA не поддерживает secondary IP-адреса на интерфейсах. Предположим, ваш восходящий поток выделяет вам / 26, маршрутизированный непосредственно на внешний интерфейс вашего ASA. Вы настраиваете интерфейс dmz своего ASA с первым IP-адресом хоста в IP-подсети, оставляя вам 64 - 2 - 1 = 61 действительный IP-адрес хоста в подсети, которые будут использоваться вашими серверами.

Если вы используете все 61 оставшийся IP-адрес хоста и вам нужно больше, вы переходите к восходящему потоку и говорите, что мне нужен еще один / 26. Они передают его вам и снова направляют напрямую на внешний IP-адрес вашего ASA. Вы не может назначьте IP-адрес первого хоста во втором блоке интерфейсу dmz вашего ASA как secondary IP-адрес, как в IOS. Это оставляет вам несколько вариантов -

Создать еще один интерфейс dmz2 на ASA (не желательно)
Верните / 26, попросите / 25 и измените нумерацию внутри (нежелательно)
Выполните статический NAT (что мы не хотим делать в этом примере)

Затем возьмем ту же парадигму - на этот раз со статическим NAT 1: 1 вне <-> dmz с самого начала. Мы используем все доступные IP-адреса в наших первых / 26 статических NAT 1: 1. Просим вторую / 26 -

Вы можете запросить восходящий маршрут напрямую к IP-адресу внешнего интерфейса ASA - экономия у вас есть несколько адресов, поскольку восходящий поток не должен назначать адрес в блоке как secondary IP-адрес включен их оборудование, которое будет использоваться в качестве шлюза, даже если оно вам не понадобится. Обратите внимание, что большинство провайдеров принимают первые 3 IP-адреса хоста как часть VRRP / HSRP, уменьшая ваши полезные ресурсы.
Если вы не запрашиваете прямую маршрутизацию блока, восходящий поток обычно выполняет вторую половину предыдущего варианта. Затем ASA проксирует ARP (как это, вероятно, происходит с вашим первым блоком, в зависимости от того, как он настроен) для локального трафика для тех IP-адресов в широковещательном домене, членом которого является внешний интерфейс.

Урок: Если у вас уже есть общедоступный IP-блок на внешнем интерфейсе, всегда запрашивайте прямую маршрутизацию последующих блоков на IP-адрес внешнего интерфейса. Это даст вам дополнительные полезные IP-адреса, и вы все равно сможете использовать статический NAT.

Независимо от прямого маршрутизации или arp прокси-сервера ASA - со статическим NAT 1: 1 вы можете начать использовать второй / 26 без необходимости возиться с подсетью dmz. После того, как вы перерастете свою подсеть dmz, вам придется кое-что приспособить - но опять же есть уровень абстракции, и вам не нужно возиться со стороны WAN.

Окончательный ответ: Это зависит от обстоятельств, но с IPv4 я склоняюсь к NAT в вашем случае.

Я бы не стал NAT. В этом нет никакой реальной ценности. Раздражающая работа по перенумерации заключается не в добавлении / удалении адресов, а в борьбе со всей ерундой, которая ее окружает, например с переносом DNS.