Причина наличия отдельной сети для межсетевых интерфейсов?

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

В чем преимущество наличия внутреннего интерфейса брандмауэра в другой подсети, чем просто в основной подсети? На диаграмме у меня есть внутренний интерфейс как 172.16.1.2, который я вижу много в примерах диаграмм. Но в чем преимущество этого просто быть другим  введите описание изображения здесь>> </a> </p></body></html>

3 голоса | спросил Matt Fogleman 7 Jpm1000000pmThu, 07 Jan 2016 23:08:04 +030016 2016, 23:08:04

5 ответов


1

Обычно брандмауэр - это маршрутизатор, поэтому обычная конфигурация для маршрутизатора имеет разные подсетей на разных интерфейсах.

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

Но в некоторых случаях полезно настроить брандмауэр как прозрачный мост (коммутатор), не влияя на архитектуру подсетей.

ответил mmv-ru 8 Jam1000000amFri, 08 Jan 2016 01:21:57 +030016 2016, 01:21:57
1

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

Учитывая брандмауэр и коммутатор уровня 3, вы действительно хотите выполнить маршрутизацию на коммутаторе уровня 3, а не на брандмауэре. Возможно, можно выполнить маршрутизацию на брандмауэре, но зачем загружать процессор на брандмауэре всеми сервисами, которые могут выполнять маршрутизаторы, такие как маршрутизация, QoS, NetFlow и т. Д., Если ваш коммутатор уровня 3 может выполнять эти службы .

Диаграмма кажется довольно простой, но на самом деле у вас наверняка будет несколько VLAN /подсети на стороне локальной сети основного коммутатора.

ответил Ron Maupin 7 Jpm1000000pmThu, 07 Jan 2016 23:19:49 +030016 2016, 23:19:49
0

На основе вашей диаграммы нет непосредственных преимуществ.

Однако я подозреваю, что внутренняя сеть сложнее, чем единая плоская локальная сеть. В этом случае «основной коммутатор» - это внутренний («межплановый») маршрутизатор. Это будет намного быстрее при выполнении маршрутизации, чем брандмауэр ever . Для начала брандмауэр представляет собой единый интерфейс («порт»), где, поскольку коммутатор имеет десятки (если не сотни) портов.

ответил Ricky Beam 8 Jam1000000amFri, 08 Jan 2016 00:54:43 +030016 2016, 00:54:43
0

На диаграмме, которую вы опубликовали, справа она ссылается на Vlan10 с сетью 10.10.0.0/24. Основываясь на этом наблюдении, вы можете сделать вывод о том, что существует сеть управления 172.16.1.x, которая будет настроена для настройки ваших устройств.

Это может быть для безопасности, вы не хотите, чтобы кто-либо в вашей компании мог получить доступ к вашим брандмауэрам web gui или переключать SSH-порты и т. д.

ответил RBMBen 8 Jam1000000amFri, 08 Jan 2016 02:04:34 +030016 2016, 02:04:34
0

Я думаю, что разделение интерфейса от внутренней сети создает дополнительную линию защиты, которая может быть весьма полезна в случае взлома брандмауэра. Я имею в виду, что помимо переключения /маршрутизации ваш коммутатор Core может иметь некоторые ACL-файлы, которые защищают ваши внутренние ресурсы и, возможно, регулируют доступ к сети 172.16.x.x. Фактически, эта отдельная сеть является своего рода DMZ.

ответил Muti Onu 19 Jpm1000000pmTue, 19 Jan 2016 12:41:49 +030016 2016, 12:41:49

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132