Внутренний NAT, также известный как NAT loopback, решает сложные проблемы NAT при доступе к веб-серверу на внешнем интерфейсе ASA или аналогичном устройстве с компьютеров на внутреннем интерфейсе. Это избавляет администраторов DNS от необходимости поддерживать дублирующую внутреннюю зону DNS, которая имеет соответствующие адреса RFC1918 для их серверов, преобразованных через NAT для общедоступных адресов. Я не сетевой инженер, поэтому мне может что-то не хватать, но это кажется легкой задачей для настройки и реализации. Асимметричная маршрутизация может быть проблемой, но ее легко решить.
По моему опыту, сетевые администраторы / инженеры предпочитают, чтобы системные специалисты просто запускали split-dns, а не настраивали свои брандмауэры для правильной обработки шпилек NAT. Почему это?
Очевидно, не может быть однозначный ответ для этого, но я мог придумать несколько причин:
Я бы не стал этого делать по нескольким причинам:
Отказ от ответственности - это ответ на приманку.
Частая причина, по которой, как мне кажется, следует избегать подобных решений, - иррациональный страх / ненависть к NAT со стороны сетевых инженеров. Если вы хотите увидеть несколько примеров обсуждения этого вопроса, посмотрите эти:
Насколько я могу судить, этот страх во многом проистекает из плохой реализации Cisco NAT (так что в этом смысле это не может быть иррациональным), но, на мой взгляд, «классический» сетевой инженер так хорошо обучен принципу «NAT - это плохое мировоззрение, что он или она не может видеть очевидных примеров, подобных этому, где это имеет смысл и фактически упрощает решение.
Вот и все - проголосуйте, сколько душе угодно! :-)
Я предполагаю:
Из плюсов для шпильки NAT,
Для небольшой сети с низкими требованиями к трафику на внутренний сервер я бы выбрал резкий NAT. Для более крупной сети с большим количеством подключений к серверу и где важны пропускная способность и задержка, используйте разделенные DNS.
С моей точки зрения, это немного изменилось между переходом Cisco Pix на ASA. Потерял alias команда. И вообще, доступ к внешнему адресу из внутреннего интерфейса брандмауэра Cisco требует некоторого обмана. Видеть: Как мне подключиться к моему внутреннему серверу по внешнему IP-адресу?
Однако нам не всегда нужно поддерживать дублирующую внутреннюю зону DNS. Cisco ASA может перенаправлять запросы DNS для внешних адресов на внутренние адреса, если они настроены в операторе NAT. Но я предпочитаю сохранить внутреннюю зону для общедоступной зоны DNS, чтобы иметь такую степень детализации и иметь возможность управлять ею в одном месте, а не шагать к брандмауэру.
Как правило, это может потребоваться всего несколько серверов в среде (почта, Интернет, несколько общедоступных служб), так что это не было большой проблемой.
Я могу назвать несколько причин:
Если бы я собирался использовать обратную петлю NAT, я бы немного беспокоился о том, как устройство NAT будет обрабатывать поддельные адреса источника. Если он не проверяет, к какому интерфейсу пришел пакет, я мог бы подделать внутренние адреса из WAN и отправить пакеты на сервер с внутренними адресами. Я не мог получать ответы, но, возможно, смогу взломать сервер, используя внутренний адрес.
Я бы настроил NAT loopback, подключился к коммутатору DMZ и отправил пакеты с поддельными внутренними адресами источника. Проверьте журнал сервера, чтобы узнать, были ли они получены. Затем я пошел бы в кофейню и посмотрел, не блокирует ли мой провайдер поддельные адреса. Если бы я обнаружил, что мой NAT-маршрутизатор не проверяет исходный интерфейс, я бы, вероятно, не стал бы использовать NAT loopback, даже если мой провайдер проверяет.