У нас есть 16 IP-адресов от нашего интернет-провайдера, и мы настраиваем SonicWall Firewall. Я бы хотел, чтобы SonicWall выполнял NAT для локальной сети, но работал как брандмауэр только (без NAT) для серверов, использующих некоторые из 16 адресов. Как мне это настроить? Если я настрою подсеть WAN на включение 16 IP-адресов, SonicWall не будет направлять трафик на интерфейс LAN. Следует ли мне настроить подсеть WAN так, чтобы она включала только те, которые мы выделяем для NAT, а затем оставить остальные в локальной сети?
Связанный вопрос: Как я могу установить несколько IP-адресов для интерфейса SonicWall LAN?
РАЗЪЯСНЕНИЕ: Серверы не имеют NAT; они напрямую используют свои публичные IP-адреса.
Как Том предложил в комментариях, вам нужно настроить статический NAT 1: 1 для ваших (я надеюсь) общедоступных серверов DMZ. Ваш исходный NAT (вероятно, многие к одному) позволит вашей подсети локальной сети использовать NAT как один из ваших / 16 соответственно.
Например:
Настроив локальную сеть и сети DMZ в отдельных подсетях (независимо от того, используете ли вы виртуальные локальные сети или отдельный интерфейс на брандмауэре; он должен иметь интерфейс «DMZ» или «Необязательный»), которые маршрутизируются и фильтруются вашим брандмауэром, вы можете теперь настройте NAT 1: 1 для статического назначения адреса DMZ общедоступному адресу, но также есть настройку фильтрации для разрешения входящего трафика из Интернета и из вашей локальной сети (и наоборот, скажем, если один из ваших серверов должен взаимодействовать с контроллером домена внутри) только на тех портах и исходных IP-адресах, которые вы хотите.
Для остального мира ваши серверы кажутся "внешними", но на самом деле они изолированы от / от Интернета и от / до вашей локальной сети, повышая безопасность, позволяя создавать правила для входящего трафика для Интернет-трафика, а также исходящий правила, чтобы сказать, разрешают веб-серверу только принимать установленные входящие соединения 80/443, но не позволяют ему инициировать исходящие соединения к любому порту TCP / UDP (и, таким образом, добавляя уровень защиты от зомбированного трафика ботнета, спам-ботов и т. ваш веб-сервер, потому что скомпрометирован).
Если ваши серверы НЕ находятся за вашим брандмауэром, вы не получите никаких преимуществ от брандмауэра, централизованного ведения журнала брандмауэра и т. Д., И это не очень хорошо.
Копнув немного дальше (и сделав шаг назад, чтобы подумать об этом), вы могли бы создать прозрачный шлюз подсети с прокси-ARP, как описано в RFC 1027 а также в этом Документ KB от SonicWall. Я не уверен, является ли ваш брандмауэр одной из поддерживаемых моделей, но это должно сработать для вас.
РЕДАКТИРОВАТЬ: в зависимости от того, что вы делаете, вам может потребоваться использовать режим моста 2 уровня или прозрачный режим; видеть этот документ для сравнения двух.