Настройка dmz на роутере cisco

Обновлено: 06.07.2024

Очень многие Wi_Fi роутеры имеют функцию предоставления доступа из внешней сети к устройствам в своей локальной сети (режим DMZ host, оно же exposed host). В этом режиме у устройства (компьютера, видеорегистратора, IP-камера, и т.д.) в локальной сети открыты все порты. Это не вполне соответствует каноническому определению DMZ, так как устройство с открытыми портами не отделяется от внутренней сети. То есть DMZ-хост может свободно подключиться к ресурсам во внутренней сети, в то время как соединения с внутренней сетью из канонического DMZ блокируются разделяющим их фаерволом, т.е. с точки зрения безопасности решение не самое лучшее. Следует помнить, что это всего один из способов организации доступа к устройству в другой локальной сети. Популярен ещё простой проброс портов. Его тоже поддерживает практически любой современный и не очень роутер. Но есть одно существенное отличие. С настройкой DMZ справится любой школьник, а вот проброс портов не так прост для человека, который делает подобное впервые.

Ввести в настройках DMZ роутера IP видеорегистратора
Роутер должен получать от провайдера постоянный IP или должен использоваться DDNS

Почему для DMZ требуется именно постоянный IP адрес, и почему его можно заменить DDNS?

Тут всё просто. Если вашему роутеру будут присваиваться провайдером разные IP-адреса, то узнать какой IP сейчас у вашего роутера можно будет с помощью сервиса DDNS. А вам необходимо знать этот самый IP адрес, чтобы подсоединиться удалённо к вашему устройству. DDNS - позволяет пользователям получить субдомен, который будет привязан к пользовательскому устройству. Зная этот субдомен, вам будет не нужно беспокоиться, его вы и будете использовать вместо IP. Однако, постоянный IP от провайдера, и проще, и безопаснее, но дороже :)

Видите как просто. В этом и есть удобство DMZ. Ещё одним плюсом является, возможность настройки маршрутизатора (роутера) не зная какой порт будет выбран для допустим видеорегистратора. И как следствие дальнейшая смена порта доступа, независимо от настроек маршрутизатора.

Проброс портов через роутер

Буквально два слова про проброс портов вцелом. Проброс портов можно было бы назвать частным случаем DMZ если бы не то, что DMZ в том виде, в котором он реализован на домашних роутерах не появился бы позже термина проброс порта. Многие пользователи не понимают смысла слова порт. Можно, если угодно расценивать порт, как цифровую метку (в виде цифры) на пакетах, помогающую сортировать информационные пакеты по назначению. Своего рода дополнительное средство маршрутизации. Как правило в настройках роутера присутствует пункт переадресация портов. Для этого следует указать IP устройства в сети роутера, порт(т.е. ту самую метку) по которому это устройство доступно по управлению, внешний порт - это порт который будет привязан к указанным порту и IP устройства.

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

Главная Cisco ISR4331-SEC/K9 через 1 порт соединена с коммутатором (L3): Dell EMC S4128T-ON на порт 3, а уже за ним хосты Dell PowerEdge R640.

На коммутаторе будет создана виртуальная сеть, т.е. VLAN – которые я уже потом буду назначать на сетевом интерфейсе различных виртуальных машин.

Первым делом нужно попросить Вашего провайдера об услуге покупки необходимого пула IP адресов, у меня к примеру: провайдер на мой внешний IP адрес завернул сеть 190.30.202.98/28 и определил, что мой внешний IP это статический роутер для доступа. Ну как-то так, я пока не силен в правильной терминологии.

Шаг №1: на Cisco ISR4331-SEC/K9

$ ssh -l admin@WAN_IP_CISCO

Т.е. 50 это название VLANа.

Связываем Cisco и EMC

interface ethernet1/1/3

switchport mode trunk

switchport trunk allowed vlan 40,50

no shutdown

Где VLAN 40 (маска подсети: /30 (255.255.255.252) – это определенная сеть, которая через switchport mode trunk связывает Cisco & EMC, так во всех лабораторных связывают одно устройство с другим

На коммутаторе Dell EMC S4128T-ON создаем/(Принимаем) VLAN DMZ-сети:

no shutdown

description dmz

Назначаю интерфейсам на коммутаторе куда подключены хосты (Сервера) данный VLAN где хочу видеть публичные сервисы, к примеру, если у Вас на хост приходит два сетевых адаптера, то:

interface ethernet1/1/19

switchport mode trunk

switchport access vlan 1

switchport trunk allowed vlan 50,111,112

no shutdown

exit

interface ethernet1/1/20

switchport mode trunk

switchport access vlan 1

switchport trunk allowed vlan 50,111,112

no shutdown

exit

Где VLAN 50 – Это VLAN организации DMZ сервиса, когда данный VLAN назначен виртуальной машине, но можно и физической, нужно в настройках хоста прописать адресацию на сетевой интерфейс вида определенного маской подсети купленного пула , т.е. в моем случае это:

Address: 190.30.202.100
Netmask: 255.255.255.240
Gateway: указываю IP адрес внутреннего Sub-интерфейса, т.е. 190.30.202.99
А DNS: к примеру 8.8.8.8

Где VLAN 111,112 – это VLAN для различных сервисов

После чего все должно заработать, можно как с Cisco пропинговать данный внешний адрес если не заблокировано брандмауэром на хосте или какими-либо правилами, так и хоста с назначенным IP адресом DMZ пула. Интернет должен работать. Правила доступа из вне настраиваются если в Sub-интерфейс добавить access-list.

Также хочу поблагодарить моего друга за помощь в понимании всего процесса, который объясняет, как настроить и использовать DMZ на Cisco в рабочей среде.

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

Итого задача выполнена. На этом я прощаюсь, с уважением автор блога Олло Александр aka ekzorchik.

Этот документ был переведен Cisco с помощью машинного перевода, при ограниченном участии переводчика, чтобы сделать материалы и ресурсы поддержки доступными пользователям на их родном языке. Обратите внимание: даже лучший машинный перевод не может быть настолько точным и правильным, как перевод, выполненный профессиональным переводчиком. Компания Cisco Systems, Inc. не несет ответственности за точность этих переводов и рекомендует обращаться к английской версии документа (ссылка предоставлена) для уточнения.

Содержание

Введение

Этот документ содержит простой пример настройки трансляции сетевых адресов (NAT) и списков контроля доступа (ACL) на межсетевом экране ASA для разрешения исходящих, а также входящих подключений. В этом документе описывается межсетевой экран с устройством адаптивной защиты (ASA) 5510, на котором работает версия кода ASA 9.1(1), но его можно легко применить к любой другой платформе межсетевого экрана ASA. Если используется платформа вроде ASA 5505, где используется VLAN вместо физического интерфейса, то необходимо соответствующим образом изменить типы интерфейсов.

Предварительные условия

Требования

Для этого документа отсутствуют особые требования.

Используемые компоненты

Содержащееся в этом документе описание построено на примере межсетевого экрана ASA 5510, на котором работает код ASA версии 9.1(1).

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Обзор

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

Разрешить хостам с внутренней стороны и в DMZ исходящее подключение к Интернету.
Разрешить хостам в Интернете доступ к веб-серверу в DMZ с IP-адресом 192.168.1.100.

Прежде чем перейти к шагам, которые необходимо выполнить для достижения этих двух целей, в этом документе приводится краткий обзор способов работы списков ACL и NAT на более новых версиях кода ASA (версия 8.3 и более поздние).

Обзор списка контроля доступа

Списки контроля доступа (сокращенно «списки доступа» или ACL) являются методом, которым межсетевой экран ASA определяет, является ли трафик разрешенным или запрещенным. По умолчанию трафик, который проходит от более низкого к более высокому уровню безопасности, запрещен. Это можно переопределить в ACL, примененном к соответствующему интерфейсу безопасности нижнего уровня. Также ASA по умолчанию разрешает трафик от интерфейсов с более высоким к интерфейсам с более низким уровнем безопасности. Это поведение можно также переопределить в ACL.

В более ранних версиях кода ASA (8.2 и ранее) ASA сравнивал входящее подключение или пакет со списком ACL на интерфейсе, не отменяя сначала трансляцию пакета. Другими словами, ACL должен был разрешить пакет, как если бы требовалось перехватить этот пакет на интерфейсе. В коде версии 8.3 и более поздних версий ASA не преобразовывает пакет до проверки списков ACL интерфейса. Это означает, что для кода версии 8.3 и более поздних версий, как и в этом документе, разрешается трафик на реальный IP-адрес хоста, а не транслированный.

Обзор NAT

NAT на ASA в версии 8.3 и более поздних разделяется на два типа, известные как автоматическая NAT (Object NAT) и ручная NAT (Twice NAT). Первая из них, Object NAT, настраивается в определении сетевого объекта. Пример этого представлен далее в этом документе. Одно основное преимущество этого метода NAT состоит в том, что ASA автоматически упорядочивает правила для обработки, во избежание конфликтов. Это самая простая форма NAT, но с ней связано ограничение на глубину детализации конфигурации. Например, нельзя принять решение о трансляции на основе назначения в пакете, как можно сделать с помощью второго типа NAT — ручной NAT. Ручная NAT обеспечивает более глубокую детализацию, но требует настройки линий в правильном порядке, чтобы можно было добиться правильной работы. Это делает данный тип NAT сложнее, из-за чего он не будет использоваться в этом примере конфигурации.

Настройка

Начать работу

Базовая конфигурация ASA — это три интерфейса, связанных с тремя сегментами сети. Сегмент сети ISP подключен к интерфейсу Ethernet0/0 и маркирован outside с уровнем безопасности 0. Внутренняя сеть подключена к Ethernet0/1 и маркирована как inside с уровнем безопасности 100. Сегмент DMZ, где располагается веб-сервер, подключен к Ethernet0/2 и маркирован как DMZ с уровнем безопасности 50.

Конфигурация интерфейса и IP-адреса для примера показаны здесь:

Здесь можно видеть, что интерфейс ASA inside установлен с IP-адресом 192.168.0.1, и это шлюз по умолчанию для внутренних хостов. Интерфейс ASA inside настроен с IP-адресом, полученным от интернет-провайдера. Установлен маршрут по умолчанию, который задает следующий переход на шлюз интернет-провайдера. При использовании DHCP это выполняется автоматически. Интерфейс DMZ настроен с IP-адресом 192.168.1.1, и это шлюз по умолчанию для хостов на сегменте сети DMZ.

Топология

Вот наглядная схема прокладки кабелей и конфигурации:

Шаг 1. Настройка NAT для разрешения выхода хостов в Интернет

В этом примере используется Object NAT, называемая также AutoNAT. Первое, что необходимо настроить, — правила NAT, разрешающие хостам в сегментах inside и DMZ подключаться к Интернету. Поскольку эти хосты используют частные IP-адреса, необходимо преобразовать их в такие адреса, которые маршрутизируются в Интернете. В данном случае преобразуйте адреса так, чтобы они были похожи на IP-адрес интерфейса ASA outside. Если ваш внешний IP часто изменяется (возможно, из-за DHCP), то это самый прямой способ настройки.

Для настройки такой NAT необходимо создать сетевой объект, представляющий подсеть inside, а также объект, представляющий подсеть DMZ. В каждом из этих объектов настройте правило динамического преобразования сетевых адресов, которое будет выполнять трансляцию адресов портов (PAT) этих клиентов, поскольку они проходят от соответствующих интерфейсов к интерфейсу outside.

Эта конфигурация выглядит примерно так:

При рассмотрении рабочей конфигурации на этом этапе (с выводом команды show run) будет видно, что определение объекта разделено на две части выходных данных. Первая часть только указывает на то, что находится в объекте (хост/подсеть, IP-адрес и т. д.), в то время как второй раздел показывает, что правило NAT связало с этим объектом. Если взять первую запись из предыдущих выходных данных, произойдет следующее:

Когда хосты, которые соответствуют подсети 192.168.0.0/24, проходят от интерфейса inside к интерфейсу outside, вам требуется динамично транслировать их в интерфейс outside.

Шаг 2. Настройка NAT для доступа к веб-серверу из Интернета

Теперь, когда хосты на интерфейсах inside и DMZ могут выходить в Интернет, необходимо изменить конфигурацию так, чтобы пользователи в Интернете могли обращаться к нашему веб-серверу через порт TCP 80. В данном примере настройка состоит в том, чтобы пользователи Интернета могли подключаться к другому IP-адресу, предоставленному интернет-провайдером, — дополнительному IP-адресу, которым мы владеем. Для данного примера используйте адрес 198.51.100.101. С этой конфигурацией пользователи Интернета смогут получить доступ к веб-серверу DMZ путем обращения к адресу 198.51.100.101 через порт TCP 80. Используйте в этой задаче Object NAT, и ASA преобразует порт TCP 80 на веб-сервере (192.168.1.100) так, чтобы он выглядел подобно 198.51.100.101 на порту TCP 80 на интерфейсе outside. Как и в прошлый раз, определите объект и задайте правила трансляции для того объекта. Кроме того, определите второй объект для представления IP-адреса, в который будет транслироваться данный хост.

Эта конфигурация выглядит примерно так:

Подытожим, что означает это правило NAT в данном примере:

Когда хост, который соответствует IP-адресу 192.168.1.100 на сегментах DMZ, устанавливает соединение, полученное от порта TCP 80 (www), и это соединение выходит через интерфейс outside, вам требуется преобразовать его в порт TCP 80 (www) на интерфейсе outside и преобразовать этот IP-адрес в 198.51.100.101.

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

Когда хосты на интерфейсе outside устанавливают подключение к 198.51.100.101 на порту TCP 80 (www) назначения, вы преобразуете IP-адрес назначения в 192.168.1.100, а портом назначения будет TCP 80 (www), и отправите его во внешнюю среду из DMZ.

В такой формулировке это имеет больше смысла. Затем необходимо настроить списки ACL.

Шаг 3. Настройка списков ACL

NAT настроена, уже недалеко осталось до завершения конфигурации. Помните, что списки ACL на ASA позволяют переопределить поведение системы безопасности по умолчанию, которое является следующим:

Трафик, который идет от интерфейса с более низким уровнем безопасности, запрещается, когда он переходит к интерфейсу с более высоким уровнем безопасности.
Трафик, который идет от интерфейса с более высоким уровнем безопасности, разрешается, когда он переходит к интерфейсу с более низким уровнем безопасности.

Таким образом, без добавления списков ACL в конфигурацию этот трафик в примере работает:

Хосты на интерфейсе inside (уровень безопасности 100) могут подключаться к хостам на интерфейсе DMZ (уровень безопасности 50).
Хосты на интерфейсе inside (уровень безопасности 100) могут подключаться к хостам на интерфейсе outside (уровень безопасности 0).
Хосты на интерфейсе DMZ (уровень безопасности 50) могут подключаться к хостам на интерфейсе outside (уровень безопасности 0).

Однако следующий трафик будет запрещен:

Хосты на интерфейсе outside (уровень безопасности 0) не смогут подключаться к хостам на интерфейсе inside (уровень безопасности 100).
Хосты на интерфейсе outside (уровень безопасности 0) не смогут подключаться к хостам на интерфейсе DMZ (уровень безопасности 50).
Хосты на интерфейсе DMZ (уровень безопасности 50) не смогут подключаться к хостам на интерфейсе inside (уровень безопасности 100).

Поскольку трафик от outside к DMZ запрещен ASA в текущей конфигурации, пользователи в Интернете не смогут получить доступ к веб-серверу, несмотря на конфигурацию NAT на шаге 2. Необходимо явно разрешить этот трафик. В коде версии 8.3 и более поздних необходимо использовать реальный IP-адрес хоста в ACL, а не преобразованный IP-адрес. Это означает, что конфигурации нужно разрешать трафик, предназначенный для адреса 192.168.1.100, а НЕ трафик, предназначенный для адреса 198.51.100.101 на порту 80. Для простоты объекты, определенные в шаге 2, будут также использоваться для этого ACL. Как только ACL создан, необходимо применить его к входящему трафику на внешнем интерфейсе.

Вот как выглядят команды настройки:

Состояния строк списка доступа:

Разрешить трафик от any (где) к хосту, представленному объектом webserver (192.168.1.100) на порту 80.

Важно, чтобы в конфигурации здесь использовалось ключевое слово any (любой). Поскольку IP-адрес источника клиентов неизвестен при его поступлении на ваш веб-сайт, укажите любое значение Any IP address (Любой IP-адрес).

Как насчет трафика от сегмента DMZ, предназначенного для хостов на сегменте сети inside? Например, сервер в сети inside, к которому требуется подключаться хостам из DMZ. Как ASA может разрешать только определенный трафик, предназначенный для сервера inside, и блокировать все остальное, предназначенное для сегмента inside из DMZ?

В данном примере предполагается, что существует сервер DNS во внутренней сети по IP-адресу 192.168.0.53, к которому хостам из DMZ требуется доступ для разрешения DNS. Вы создаете необходимый ACL и применяете его к интерфейсу DMZ таким образом, чтобы ASA мог переопределить поведение системы безопасности по умолчанию, упомянутое ранее, для трафика, который входит на этот интерфейс.

Вот как выглядят команды настройки:

ACL сложнее, чем простое разрешение трафика к серверу DNS на порт UDP 53. Если бы мы реализовали только первую строку permit (разрешить), то весь трафик из DMZ к хостам в Интернете блокировалось бы. В конце списков ACL неявно задается настройка deny ip any any. В результате ваши хосты DMZ не могли бы выйти в Интернет. Даже при том, что трафик от DMZ к outside разрешен по умолчанию, с применением ACL к интерфейсу DMZ такое поведение системы безопасности по умолчанию для интерфейса DMZ больше не действует, и необходимо явно разрешить трафик в ACL интерфейса.

Шаг 4. Тестирование конфигурации с помощью функции трассировщика пакетов

Теперь, когда конфигурация завершена, необходимо протестировать ее, чтобы удостовериться, что она работает. Самый простой способ — использовать действующие хосты (если это ваша сеть). Однако в интересах тестирования из интерфейса командной строки и дальнейшего исследования некоторых программных средств ASA используйте трассировщик пакетов, чтобы протестировать и потенциально отладить любые возможные проблемы.

Трассировщик пакетов работает путем моделирования пакета на основе серии параметров и внедрения этого пакета в канал передачи данных интерфейс, подобно способу, которым внедрялся бы реальный пакет в случае снятия с канала. Этот пакет следует через большое число проверок и процессов, которые выполняются по мере его прохождения через межсетевой экран, и трассировщик пакетов фиксирует результат. Моделируйте внутренний хост, выходящий на хост в Интернете. Приведенная ниже команда сообщает межсетевому экрану сделать следующее:

Моделировать пакет TCP, поступающий в интерфейс inside с IP-адреса 192.168.0.125 на порту источника 12345 и предназначенный для IP-адреса 203.0.113.1 на порту 80.

Конечным результатом является то, что трафик разрешается, то есть он прошел все проверки NAT и ACL в конфигурации и был отправлен из исходящего интерфейса — outside. Обратите внимание на то, что пакет был преобразован в фазе 3 и подробные сведения об этой фазе показывают, какое правило задействовано. Хост 192.168.0.125 динамически преобразуется в 198.51.100.100 согласно конфигурации.

Теперь запустите ее для подключения из Интернета к веб-серверу. Помните, хосты в Интернете обращаются к веб-серверу путем подключения к 198.51.100.101 на интерфейсе outside. Опять же, эта следующая команда преобразовывается в следующее:

Моделировать пакет TCP, поступающий в интерфейс outside с IP-адреса 192.0.2.123 на порту источника 12345 и предназначенный для IP-адреса 198.51.100.101 на порту 80.

Опять же, результат состоит в том, что пакет разрешается. Проверки ACL пройдены, конфигурация выглядит хорошо, и пользователи в Интернете (outside) должны быть в состоянии обратиться к данному веб-серверу с помощью внешнего IP-адреса.

Проверка

Процедуры проверки включены в Шаг 4. Тестирование конфигурации с функцией трассировщика пакетов.

Устранение неполадок

Для этой конфигурации в настоящее время нет сведений об устранении проблем.

Заключение

Настройка ASA для выполнения базовой NAT — не такая сложная задача. Приведенный в этом документе пример можно адаптировать к конкретному сценарию, если изменить IP-адреса и порты, используемые в примерах конфигурации. Окончательная конфигурация ASA при сочетании всего этого выглядит примерно так для ASA 5510:

На ASA 5505, например, с интерфейсами, подключенными, как показано ранее (outside подключен к Ethernet0/0, inside к Ethernet0/1, а DMZ к Ethernet0/2):

>Есть cisco 2821 c двумя интерфейсами.
>Один в WAN, второй в LAN.
>Работает NAT, организованно около 10 VPN туннелей с серверами FreeBSD на удаленном
>конце.
>Теперь встал вопрос об организации DMZ (почта,www,jabber).
>Как я понял нужно использовать для этого сабинтерфейсы.
>В наличии из свичей есть только 3COM 4400SE и Dlink DES-2108.
>Собственно вопрос, пойдут ли эти свичи для совместной работы с cisco для
>организации DMZ или придется раскошеливаться на HWIC-4ESW?

Если dot1Q поддерживают, то подойдут.

>Если можно пример конфига по организации DMZ.

Примерно так .

interface FastEthernet0/0
no ip address
duplex auto
speed auto
!
interface FastEthernet0/0.1
encapsulation dot1Q 1
ip address 10.10.10.1 255.255.255.0
no ip redirects
!
interface FastEthernet0/0.2
encapsulation dot1Q 2
ip address 10.10.11.1 255.255.255.0
no ip redirects

Пока получилось примерно так:
192.168.1.0/24 локалка
настроил все на dlink (10.0.10.1)
локалка пингуется, то есть dot1q работает
Но не получается теперь опубликовать сервера в DMZ зоне, точнее не могу понять как это сделать.
Скажем есть сервер www,ftp с адресом 217.0.0.100
и mail сервер c адресом 217.0.0.98. Сервера находятся в одной подсетке.
На сетевых карточках серверов прописаны реальные адреса.
interface GigabitEthernet0/0
description LAN interface
ip address 10.0.10.1 255.255.255.0
ip access-group 103 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip virtual-reassembly
duplex auto
speed auto
no mop enabled
!
interface GigabitEthernet0/0.3
description to intranet
encapsulation dot1Q 3
ip address 192.168.1.248 255.255.255.0
ip nat inside
ip virtual-reassembly
no cdp enable
!
interface GigabitEthernet0/1
description WAN
ip address 217.x.x.101 255.255.255.248
ip access-group 104 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip wccp web-cache redirect out
ip nat outside
ip inspect SDM_LOW out
ip virtual-reassembly
ip route-cache policy
duplex auto
speed auto

>Пока получилось примерно так:
>
>192.168.1.0/24 локалка
>настроил все на dlink (10.0.10.1)
На D-Link-е IP address не нужен
>локалка пингуется, то есть dot1q работает
>Но не получается теперь опубликовать сервера в DMZ зоне, точнее не могу
>понять как это сделать.
>Скажем есть сервер www,ftp с адресом 217.0.0.100
>и mail сервер c адресом 217.0.0.98. Сервера находятся в одной подсетке.
>На сетевых карточках серверов прописаны реальные адреса.
Если на серверах "белые" адреса, разбей 217.x.x.x на две подсети, одну снаружи, вторую на интерфейс, где DMZ.
Или поставь на серверах "серые" адреса и через
ip nat inside source static tcp 192.168.100.1 80 217.x.x.A 80 extendable
ip nat inside source static tcp 192.168.100.2 25 217.x.x.B 25 extendable
Тогда на DMZ интерфейсе нужен еще NAT.

Взял еще адресов.
217.x.x.96/29 dmz сеть
89.x.x.224/29 wan
Шлюз провайдера для каждой сети соответственно 217.x.x.97 и 89.x.x.225
получилось:

interface GigabitEthernet0/0
description LAN Interface
ip address 192.168.1.248 255.255.255.0
ip access-group 103 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
ip flow egress
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
no mop enabled
!
interface GigabitEthernet0/0.100
description interface DMZ
encapsulation dot1Q 100
ip address 217.x.x.101 255.255.255.248
no cdp enable
!
interface GigabitEthernet0/1
description WAN interface
ip address 89.x.x.226 255.255.255.248
ip access-group 104 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip wccp web-cache redirect out
ip flow egress
ip nat outside
ip inspect SDM_LOW out
ip virtual-reassembly
ip route-cache policy
duplex auto
speed auto
no mop enabled
crypto map vpnmap

ip route 0.0.0.0 0.0.0.0 89.x.x.225 permanent

После подключения всей схемы сервера в DMZ (217.x.x.98, 217.x.x.100) видят только друг друга. Шлюз провайдера 217.x.x.97 они не видят.
Странно следующее. На одном сервере в DMZ настроен NAT. Шлюзом для сервера прописан все тот же 217.x.x.97. На этом сервере исторически осталась еще сетевая карта смотрящая в локалку. Так вот локальные компьютеры имеющие гейтом этот сервер из dmz по внутренней сетевой карте имеют работающий интернет, хотя оговорюсь еще раз с самого сервера шлюз провайдера и соответственно выход в инет не работает.

>Взял еще адресов.
>217.x.x.96/29 dmz сеть
>89.x.x.224/29 wan
>Шлюз провайдера для каждой сети соответственно 217.x.x.97 и 89.x.x.225
>получилось:
>
>interface GigabitEthernet0/0
> description LAN Interface
> ip address 192.168.1.248 255.255.255.0
> ip access-group 103 in
> no ip redirects
> no ip unreachables
> no ip proxy-arp
> ip flow ingress
> ip flow egress
> ip nat inside
> ip virtual-reassembly
> duplex auto
> speed auto
> no mop enabled
>!
>interface GigabitEthernet0/0.100
> description interface DMZ
> encapsulation dot1Q 100
> ip address 217.x.x.101 255.255.255.248
> no cdp enable
>!
>interface GigabitEthernet0/1
> description WAN interface
> ip address 89.x.x.226 255.255.255.248
> ip access-group 104 in
> no ip redirects
> no ip unreachables
> no ip proxy-arp
> ip wccp web-cache redirect out
> ip flow egress
> ip nat outside
> ip inspect SDM_LOW out
> ip virtual-reassembly
> ip route-cache policy
> duplex auto
> speed auto
> no mop enabled
> crypto map vpnmap
>
>ip route 0.0.0.0 0.0.0.0 89.x.x.225 permanent
>
>После подключения всей схемы сервера в DMZ (217.x.x.98, 217.x.x.100) видят только друг
>друга. Шлюз провайдера 217.x.x.97 они не видят.
>Странно следующее. На одном сервере в DMZ настроен NAT.
NAT убрать.

> Шлюзом для сервера
>прописан все тот же 217.x.x.97.
Default gateway для всех кто в DMZ 217.x.x.101. Маски сетей проверить.

> На этом сервере исторически осталась еще
>сетевая карта смотрящая в локалку.
Лишние сетевые выкинуть.

Прописал для компов в DMZ шлюз 217.x.x.101
Инет не работает все равно.
Я так понимаю нужно как то указать, что это вся подсетка роутится через ip провайдера 217.x.x.97. Но где.

Соответственно с cisco ip адрес 217.x.x.97 тоже не пингуется.
Если я на WAN интерфейсе прописываю ip из 217 то пинг на 217.x.x.97 проходит.

>Соответственно с cisco ip адрес 217.x.x.97 тоже не пингуется.
>Если я на WAN интерфейсе прописываю ip из 217 то пинг на
>217.x.x.97 проходит.

sh ip ro что говорит?

>>Соответственно с cisco ip адрес 217.x.x.97 тоже не пингуется.
>>Если я на WAN интерфейсе прописываю ip из 217 то пинг на
>>217.x.x.97 проходит.
>
>sh ip ro что говорит?
И еще
ping 89.x.x.225 sou gi0/0.100
ping IP-сервера-в DMZ sou gi0/0.100

>>пинг с cisco на 217.x.x.97 не проходит.
>А такого хоста и нету.
>Значит все работает.
Да, работает,но с серверов в DMZ я кроме DMZ зоны ничего не вижу.
То есть сетка 217.x.x.96/29 не маршрутизируется через 89.x.x.225
Она маршрутизируется только через 217.x.x.97.

>
>>>пинг с cisco на 217.x.x.97 не проходит.
>>А такого хоста и нету.
>>Значит все работает.
>
>Да, работает,но с серверов в DMZ я кроме DMZ зоны ничего не
>вижу.
>То есть сетка 217.x.x.96/29 не маршрутизируется через 89.x.x.225
>Она маршрутизируется только через 217.x.x.97.

Пинай провайдера.

>К провайдеру ушел, а обратно не пришел. Акцесс-лист на входе? Маршрутизация у
>провайдера не настроена?
Большое спасибо за вашу поддержку.
Акцесс лист с gig0/1 я убирал для чистоты эксперимента. Проблему это не решило.
Как нибудь можно проверить маршрутизацию, настроена она или нет у провайдера?
Или если у меня роутинг в данном случае не работает, значит не настроена?
Подскажите плиз, какие именно настройки должен изменить у себя провайдер?

Не претендуя на полноту изложения, попробую описать технологии, которыми можно воспользоваться для защиты периметра.

Рассматривать будем IOS с firewall feature set. Этот набор возможностей, как правило, есть во всех IOSах (в которых есть шифрование), кроме самого базового.

Итак, пусть на границе нашей сети стоит машрутизатор cisco, который и призван обеспечивать безопасность наших внутренних ресурсов.

Защищаем трафик.

Первым делом имеет смысл порезать ненужный трафик самым простым и грубым способом — списками доступа.

Списки доступа (ACL, Access Control List) для протокола IP — на маршрутизаторах cisco бывают стандартные (проверяют только ip адрес источника и разрешают или запрещают прохождение трафика по этому параметру) и расширенные (проверяют адреса источника и назначения, протокол передачи, порты источника и назначения, а также другие поля заголовков IP, TCP, UDP и других протоколов).

Порядок строк в списке доступа очень важен, т.к. проверяются эти строки по порядку и как только будет найдено совпадение, пакет или будет пропущен или будет уничтожен

В конце любого ACL непременно стоит невидимое «запретить все», поэтому мимо ACL пакет не проскользнёт.

Списки доступа бывают нумерованные и поименованные. Рекомендую использовать поименованные со смысловыми названиями.

Примеры:
access-list 1 permit 192.168.1.0 0.0.0.255

access-list 101 permit ip any 192.168.1.0 0.0.0.255

ip access-list standard TEST
permit host 1.2.3.4

Сам по себе список доступа ничего не делает, пока не будет применен для какой либо технологии. Например, для фильтрации трафика на интерфейсе на вход или на выход ACL применяется командой

ip access-group <название ACL>

Традиционно рекомендуется на внешний интерфейс вешать так называемый антиспуфинговый ACL, т.е. предотвращающий атаки с подделанных адресов.

Пример:
ip access-list ex ANTISPOOFING
deny ip host 0.0.0.0 any
deny ip 10.0.0.0 0.255.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
deny ip host 255.255.255.255 any
deny ip 224.0.0.0 15.255.255.255 any
permit ip any any

Важно: с таким ACL надо быть очень осторожным в случае, если вы работаете с шифрованными туннелями IPSec. Дело в том, что ACL, висящий на вход интерфейса, проверяет сначала заголовок зашифрованного пакета, а потом — заголовок расшифрованного.

Поэтому запрет трафика от частных сетей (10, 172, 192) может нарушить работу туннеля.

Итак, порезали ненужный трафик. Пришло время заняться межсетевым экранированием. Надо обеспечить внутренних пользователей Интернетом, но при этом не пропустить снаружи внутрь несанкционированные подключения. Маршруизаторы cisco умеют быть межсетевыми экранами с сохранением сессий (stateful firewall).

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

Для этого надо создать правило ip inspect, описать те протоколы, которые вы хотите обрабатывать и запоминать сессии, привесить это правило на интерфейс и… всё :) Маршрутизатор будет запоминать те сессии, которые были инициированы изнутри, и пропускать снаружи только те пакеты, которые «заказаны». Если же пришедший пакет не соответствует никакой сессии, то дальше маршрутизатор проверяет ACL, висящий на интерфейсе, на предмет наличия разрешающего правила для этого пакета.

ответного пакета TCP/UDP сессии. Например, протокол FTP имеет один служебный канал, по которому идёт согласование и аутентификация, а данные передаются совсем по другому каналу, причём сессия пытается инициироваться снаружи и маршрутизатор её не пропустит. А если включить инспектирование, маршрутизатор подслушает служебную сессию, узнает, на каких портах сервер и клиент договорились слать данные и эту сессию тоже поместит в список разрешенных.

Пусть f0/0 — внешний, а f0/1 — внутренний интерфейс

Правило вешается на вход внутреннего или выход внешнего интерфейса, т.е. в направлении на ВЫХОД трафика наружу.

На внешнем интерфейсе висит строгий ACL, который почти ничего не пропускает снаружи, например

Есть тонкость: ACL STRICT попутно запретит весь трафик на сам роутер, т.к. по умолчанию трафик роутера не попадает в инспектируемый. Чтобы инспектировать трафик маршрутизатора надо добавить

Если же задачи сложные, надо создавать различные зоны безопасности (демилитаризованные зоны, DMZ), гибко настраивать работу протоколов между этих зон, то лучше воспользоваться так называемым, зональным межсетевым экраном (zone-based firewall). Описывать его здесь не буду, ибо это уже не для молодого бойца :)

Чем ещё можно защитить трафик, проходящий через маршрутизатор?

системой предотвращения вторжений (IPS), промежуточной аутентификацией (cut-through proxy), оценкой протоколов (технология ip nbar), созданием очередей (QoS).

Читайте также: