Почему больше организаций не используют внутреннюю NAT или аналогичные решения для разрешения шпилек NAT?

Внутренний NAT, известный как петлевая петля NAT, решает проблемы NAT-шпилек при обращении к веб-серверу на внешнем интерфейсе ASA или аналогичного устройства с компьютеров на внутреннем интерфейсе. Это не позволяет администраторам DNS поддерживать дублирующуюся внутреннюю зону DNS, имеющую соответствующие адреса RFC1918 для своих серверов, которые NAT-адресации являются общедоступными. Я не сетевой инженер, так что я мог бы что-то упустить, но это кажется легким для настройки и реализации. Асимметричная маршрутизация может быть проблемой, но ее легко устранить.

По моему опыту, сетевые администраторы / инженеры предпочитают, чтобы системные пользователи просто запускали split-dns, а не настраивали свои брандмауэры для правильной обработки шпилек NAT. Почему это?

Есть несколько причин, по которым я бы этого не делал:

• Зачем создавать дополнительную нагрузку на маршрутизаторы и межсетевой экран DMZ, если вам это не нужно? Большинство наших внутренних служб находятся не в демилитаризованной зоне, а в общем корпоративном пространстве, с услугами прокси в демилитаризованной зоне для периодического удаленного доступа. Выполнение nat изнутри-внутрь увеличивает нагрузку на DMZ, что в нашем случае будет значительным.
• Если вы не выполните DNAT + SNAT, вы получите асимметричную маршрутизацию, которая, как известно, сложно сделать правильно. Таким образом, вы SNAT и потеряете IP-информацию источника. Однако чертовски полезно связывать исходные IP-адреса с людьми в целях устранения неполадок. Или изредка в целях глупости. «Эй, этот IP делает что-то странное на неаутентифицированном сервисе X» «О, давайте посмотрим в журналах сервера imap, кто это».

Очевидно, что не может быть определенного ответа на это, но я мог бы подумать о нескольких причинах:

1. Элегантность: NAT не очень элегантен для начала, но необходим для ограниченного адресного пространства IPv4. Если я могу избежать NAT, я буду. С IPv6 проблема исчезает в любом случае.
2. Сложность: особенно в случае, когда у вас нет только одного «основного» маршрутизатора, создающего все ваши границы безопасности, конфигурации фильтров могут стать довольно сложными. Либо так, либо вам придется распространять и поддерживать правила NAT практически на всех ваших маршрутизаторах.
3. Справка: там, где администраторы брандмауэра отличаются от остальных членов группы администраторов сервера, они могут быть труднодоступны. Чтобы гарантировать, что изменения не будут отложены из-за отставания администратора брандмауэра (или отпуска), выбран вариант сохранения ответственности в той же группе
4. Переносимость и распространенная практика: использование представлений DNS - это «только то, что все знают, что сделано» для решения этой проблемы. Не каждый граничный маршрутизатор будет поддерживать петлевой NAT простым способом, меньше людей, вероятно, будут знать, как правильно настроить его в вашей конкретной среде. При устранении неполадок в сети, экипаж должен знать о конфигурации шпильки NAT и всех ее последствиях, даже если они преследуют явно не связанную проблему

Отказ от ответственности - это флеймбайт-ответ.

Я думаю, что распространенной причиной, по которой таких решений избегают, является иррациональный страх / ненависть к NAT со стороны сетевых инженеров . Если вы хотите увидеть некоторые примеры обсуждения по этому вопросу, проверьте это:

• http://packetpushers.net/show-86-connect-to-the-ipv6-internet-for-free-using-tunnelbroker-net/
• http://networkingnerd.net/2012/04/02/ipv6-nat-and-the-sme-a-response/ (блог Тома, похоже, продолжает привлекать довольно пылкое обсуждение NAT / IPv6)
• http://libertysys.com.au/blog/nat-is-evil-but-not-bad (мой блог)

Из того, что я могу сказать, большая часть этого страха проистекает из плохой реализации Cisco NAT (так что в этом смысле это не может быть иррационально), но, на мой взгляд, «классический» сетевой инженер так хорошо обучен в «NAT is плохое мировоззрение, что он или она не может видеть очевидные примеры, подобные этому, где это имеет смысл и фактически упрощает решение.

Вот и все - понизь голос до глубины души! :-)

Мое предположение:

1. Сплит DNS легче понять.
2. NAT Hairpin использует ресурсы на маршрутизаторе, а split-dns - нет.
3. Маршрутизаторы могут иметь ограничения пропускной способности, которые вы не получаете через настройку split-dns.
4. Split-dns всегда будет работать лучше, поскольку вы избегаете шагов маршрутизации / NAT.

С положительной стороны для шпильки NAT,

• Как только он настроен, он просто работает.
• Никаких проблем с кэшем DNS для ноутбуков, перемещенных между рабочей сетью и общедоступным Интернетом.
• DNS для сервера управляется только в одном месте.

Для небольшой сети с низкими требованиями к трафику к внутреннему серверу я бы выбрал шпильку NAT. Для большой сети с большим количеством подключений к серверу, где важны пропускная способность и задержка, используйте split-dns.

С моей точки зрения, это немного изменилось между переходом Cisco Pix на ASA. Потерял aliasкоманду. И вообще, доступ к внешнему адресу из внутреннего интерфейса на брандмауэре Cisco требует некоторой хитрости. Смотрите: Как мне добраться до моего внутреннего сервера по внешнему IP?

Нам не всегда нужно поддерживать дублированную внутреннюю DNS-зону. Cisco ASA может перенаправлять запросы DNS для внешних адресов на внутренние адреса, если это настроено в инструкции NAT. Но я предпочитаю оставить внутреннюю зону для общедоступной зоны DNS, чтобы иметь такую ​​степень детализации и иметь возможность управлять этим в одном месте, а не шагать к брандмауэру.

Как правило, есть только несколько серверов, которые могут требовать этого в среде (почта, Интернет, несколько общедоступных служб), поэтому это не было огромной проблемой.

Я могу придумать несколько причин:

1. Многие организации уже разделили DNS из-за того, что не хотят публиковать всю свою внутреннюю информацию DNS в мире, поэтому не требуется особых усилий для обработки нескольких серверов, которые также доступны через публичный IP.
2. Поскольку организация и ее сеть становятся все больше, они часто отделяют системы, обслуживающие внутренних пользователей, от серверов, обслуживающих внешние, поэтому маршрутизация на внешние для внутреннего использования может оказаться гораздо более продолжительным сетевым путем.
3. Чем меньше модификаций, которые промежуточные устройства вносят в пакеты, тем лучше, когда речь идет о задержке, времени отклика, загрузке устройства и устранении неполадок.
4. (очень незначительно, по общему признанию) Существуют протоколы, которые NAT будет по-прежнему нарушать, если устройство NATing не выходит за пределы заголовков пакета и не изменяет данные в нем с новым IP-адресом (ами). Даже если это просто случай институциональной памяти, у людей все еще есть веская причина избегать этого, особенно если они имеют дело с протоколом, в котором они не уверены на 100%.

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

Я бы настроил NAT loopback, подключился к коммутатору DMZ и отправлял пакеты с поддельными внутренними адресами источника. Проверьте журнал сервера, чтобы увидеть, были ли они получены. Затем я пошел в кафе и посмотрел, не блокирует ли мой провайдер поддельные адреса. Если бы я обнаружил, что мой маршрутизатор NAT не проверяет исходный интерфейс, я бы, вероятно, не использовал обратную связь NAT, даже если мой провайдер проверяет.