Статья: настройка DMZ и VPN на Cisco PIX 8.0(3)

Обсуждаем сайт и форум.

Модератор: f0s

GhOsT_MZ
лейтенант
Сообщения: 662
Зарегистрирован: 2011-04-25 11:40:35
Контактная информация:

Статья: настройка DMZ и VPN на Cisco PIX 8.0(3)

Непрочитанное сообщение GhOsT_MZ » 2012-09-13 12:06:12

ПРЕДИСЛОВИЕ:
Недавно была поставлена задача: организовать L2L VPN между двумя Cisco PIX 8.0(3). Далее, к этой задаче «приросла» необходимость в поднятии DMZ и Remote access VPN (для удаленного доступа администратора) на одном из Cisco PIX. С одной стороны, задача типична и достаточно документации с сайта cisco.com. Но, начав настройку МСЭ, начали всплывать подводные камни, обойти которые удалось не так просто, по причине того, что описание появившихся проблем находились в неожиданных для меня местах. Собственно, хотелось бы поделиться с проблемами и их решениями, ну и помочь людям обойти грабли, на которые я наступил по глупости. Само собой, опытные специалисты по МСЭ Cisco могут закончить на этом абзаце…
PS: в написании статей я новичок, так что надеюсь на объективную критику.
PSS: статья написана немного академическим языком, если сравнивать с уже существующими статьями на этом сайте, но увы, иначе не получается. А также, здесь нету руководства к действию, а скорее раскрывается один частный случай, который, на мой взгляд, является не совсем тривиальным, и может помочь новичкам расширить свою видимость.

ЗАДАЧА:
Как уже говорилось выше, задача в организации VPN между двумя сетями, VPN удаленного доступа и демилитаризованной зоны.
Принципиальная схема сети выглядит следующим образом:
Изображение

Адресация выглядит следующим образом:
Для внутренней сети всей организации выделены адреса 172.16.0.0/12. Наше структурное подразделение имеет сеть (если это так можно назвать) 172.16.9.0/0.15.0.255, которую мы и будем использовать как для внутренней сети, так и для удаленных пользователей и офисов. Из этой «сети» мы выделим 172.20.9.0/24 под демилитаризованную зону, и 172.25-26.9.0/24 под удаленные пользователи и офисы, причем, под офис выделим сети 172.25-26.9.0/26. У нас остается 3 подсети размером /26, одну из которых мы выделим под удаленный доступ, а оставшиеся 2 – под перспективу новых офисов.
Цель: организовать доступ из удаленного офиса (172.25.9.0/26 и 172.26.9.0/26) во внутреннюю сеть и в демилитаризованную зону. Также, необходимо организовать аналогичный доступ для удаленных пользователей. Доступ в демилитаризованную зону должен быть со всех внутренних адресов, но узлы демилитаризованной зоны не должны иметь доступ во внутреннюю сеть.

РЕШЕНИЕ ЗАДАЧИ:
Прежде чем пытаться конфигурировать Cisco PIX, необходимо понять, что это МСЭ, и все принципы настройки аналогичных сетей на базе маршрутизаторов не работают с данными устройствами.
Одни из первых граблей, на которые я наступил – это маршруты. Дело в том, что имея небольшой опыт конфигурирования маршрутизаторов, я рассчитывал на то, что при поднятии туннеля, в таблицу маршрутизации будет добавляться маршрут для этого туннеля. Рассчитывая на это, я, не долго думая, добавил маршрут во внутреннюю сеть в виде:

Код: Выделить всё

route inside 172.16.0.0 255.240.0.0 172.31.9.241 20
На всякий случая увеличил метрику до 20, в надежде, что при поднятии туннеля получу маршрут в удаленную сеть с меньшей метрикой. После того, как понял, что никакие маршруты не добавляются при поднятии туннеля, пришлось «наплодить» более мелких маршрутов, предварительно убрав этот укрупненный:

Код: Выделить всё

route inside 172.16.0.0 255.255.0.0 172.31.9.241 1
route inside 172.17.0.0 255.255.0.0 172.31.9.241 1
route inside 172.18.0.0 255.255.0.0 172.31.9.241 1
route inside 172.19.0.0 255.255.0.0 172.31.9.241 1
route inside 172.21.0.0 255.255.0.0 172.31.9.241 1
route inside 172.22.0.0 255.255.0.0 172.31.9.241 1
route inside 172.23.0.0 255.255.0.0 172.31.9.241 1
route inside 172.24.0.0 255.255.0.0 172.31.9.241 1
route inside 172.27.0.0 255.255.0.0 172.31.9.241 1
route inside 172.28.0.0 255.255.0.0 172.31.9.241 1
route inside 172.29.0.0 255.255.0.0 172.31.9.241 1
route inside 172.30.0.0 255.255.0.0 172.31.9.241 1
route inside 172.31.0.0 255.255.0.0 172.31.9.241 1
И вуаля, трафик побежал куда нужно.
Вторые грабли, на которые наступил – это странная работа NAT на устройстве. Проблема заключалась в следующем: после настройки NAT при попытке отправки ICMP-пакета наружу, ответ не попадал вовнутрь, и это при том, что в таблицу трансляции этот пакет попадал. И самое что интересное, в документации по PIX не было упоминания этой проблемы, но оно было найдено в разделе траблшутинга, где было указано, что по умолчанию PIX отправляет наружу ICMP-пакеты, но ответы почему-то отбрасывает. Для PIX 8.0.3 эта проблема решается следующим образом:

Код: Выделить всё

policy-map global_policy
 class inspection_default
  …
  inspect icmp
  …
!
После выполнения данной настройки ICMP-пакеты забегали как и положено. Упомянул эту проблему по той причине, что есть привычка проверять работу сети именно пингом. Таким образом, если не настроить правильную работу с ICMP-пакетами, то и проверка работы будет недостоверной.
Эта настройка работает с 7 версии PIX. Для более ранних версий можно повесить на внешний интерфейс следующий список доступа:

Код: Выделить всё

access-list ouside extended permit icmp any any echo-reply
Определившись с данными нюансами, можно приступить к конфигурированию.
Первое, что необходимо сделать – определить пользователей, имеющих доступ во внешнюю сеть, и адрес, в который будут транслироваться внутренние адреса. Это делается следующим образом:

Код: Выделить всё

access-list pat-inside extended permit ip 172.16.9.0 255.255.255.128 any
global (outside) 1 1.1.1.2
nat-control
nat (inside) 1 access-list pat-inside
Таким образом мы определили, что внешним адресом для пользователей сети 172.16.9.0/25 будет 1.1.1.2.
Следущим шагом будет настройка L2L VPN на центральном Cisco PIX. Для этого необходимо:
1. Определить, какие пакеты необходимо шифровать и отправлять в туннель. Делается это с помощью ACL. В нашем случае он будет выглядеть следующим образом:

Код: Выделить всё

access-list ENC_BR1 extended permit ip 172.16.0.0 255.240.0.0 172.25.9.0 255.255.255.0
access-list ENC_BR1 extended permit ip 172.16.0.0 255.240.0.0 172.26.9.0 255.255.255.0
access-list ENC_BR1 extended permit ip 10.101.224.0 255.255.255.0 172.25.9.0 255.255.255.0
access-list ENC_BR1 extended permit ip 10.101.224.0 255.255.255.0 172.26.9.0 255.255.255.0
Данный ACL охватывает все исходящие пакеты из внутренних сетей, направленные в удаленные офисы и удаленным пользователям;
2. Для каких пакетов нужно запретить трансляцию адресов. Также, как и в предыдущем случае, нам необходимо использовать ACL для определения нужных адресов. Так как мы не должны транслировать адреса только для пакетов, направленных в удаленные офисы, то по сути данный ACL продублирует ACL ENC_BR1. Но при этом, желательно оформить это в виде отдельного списка доступа:

Код: Выделить всё

access-list nonat-inside extended permit ip 172.16.0.0 255.240.0.0 172.25.9.0 255.255.255.0
access-list nonat-inside extended permit ip 172.16.0.0 255.240.0.0 172.26.9.0 255.255.255.0
access-list nonat-inside extended permit ip 10.101.224.0 255.255.255.0 172.25.9.0 255.255.255.0
access-list nonat-inside extended permit ip 10.101.224.0 255.255.255.0 172.26.9.0 255.255.255.0
nat (inside) 0 access-list nonat-inside
3. Настроить таблицу преобразований:

Код: Выделить всё

crypto ipsec transform-set TSET-VPN esp-des esp-md5-hmac
4. Настроить крипто-карту, где необходимо указать, какие сетевые пакеты необходимо отправлять в туннель (ACL ENC_BR1, созданный ранее), таблицу преобразований, созданную ранее, и адрес второго конца туннеля;

Код: Выделить всё

crypto map CMAP-VPN 10 match address ENC_BR1
crypto map CMAP-VPN 10 set peer 2.2.2.2
crypto map CMAP-VPN 10 set transform-set TSET-VPN
5. Настроить ISAKMP и включить прием пакетов этого протокола на внешнем интерфейсе. Здесь важно обратить внимание, что алгоритм хэширования и алгоритм шифрования трафика должен совпадать с указанным в таблице преобразований, иначе туннель не поднимется. Также можно поиграться с этими алгоритмами, предварительно узнав поддерживаемые устройством, с помощью команды show version. Настройка ISAKMP выглядит следующим образом:

Код: Выделить всё

crypto isakmp policy 10
 authentication pre-share
 encryption des
 hash md5
 group 1
 lifetime 1000
crypto isakmp identity address
crypto isakmp enable outside
6. И последний этап настройки – настройка туннеля. В виде названия туннеля должен фигурировать адрес второго конца туннеля, а вместо звездочки в команде pre-shared-key должен быть ключ, который должен совпадать на обоих концах туннеля:

Код: Выделить всё

tunnel-group 2.2.2.2 type ipsec-l2l
tunnel-group 2.2.2.2 ipsec-attributes
 pre-shared-key *
7. Включаем прием IPSec и ISAKMP пакетов:

Код: Выделить всё

sysopt connection permit-vpn
Настройка второго Cisco PIX практически идентична вышеописанной настройке, за исключение ACL, которые должны быть зеркальными, и адреса второго конца туннеля, который должен быть заменен с 2.2.2.2 на 1.1.1.1.
На данном этапе мы имеем: выход пользователей во внешнюю сеть и связь между офисами.

Далее, необходимо настроить удаленный доступ с использованием Cisco VPN Client. Данная настройка несколько отличается от настройки L2L VPN. Главным отличием является поддержка динамических пиров. Порядок настройки выглядит следующим образом:
1. Настройка таблицы преобразований. В нашем случае она будет идентичная таблице преобразований для L2L VPN, но при этом, желательно сделать ее отдельно, что даст возможность в будущем менять ее лишь для этого типа VPN:

Код: Выделить всё

crypto ipsec transform-set TSET-RA esp-des esp-md5-hmac
2. Создание динамической крипто-карты. В отличии от не динамического L2L VPN, здесь нет необхомости указывать второй конец туннеля и определять, какие пакеты следует шифровать, так как это будет делаться динамически при поднятии туннеля. Настройка выглядит следующим образом:

Код: Выделить всё

crypto dynamic-map DMAP-RA 1 set transform-set TSET-RA
crypto map CMAP-VPN 1 ipsec-isakmp dynamic DMAP-RA
3. Настройка ISAKMP политики:

Код: Выделить всё

crypto isakmp policy 65535
 authentication pre-share
 encryption des
 hash md5
 group 2
 lifetime 86400
Другие настройки, такие как привязка крипто карты к внешнему интерфейсу, можно опустить, так как это было сделано ранее.
Далее, необходимо настроить аутентификацию пользователей и настройку их клиентов. Для начала определим адреса, которые будем выдавать удаленным пользователям:

Код: Выделить всё

ip local pool RAPool 172.25.9.240-172.25.9.254 mask 255.255.255.192
В Cisco PIX начиная с 7.х версий (если память не изменяет) появились достаточно гибкие настройки групповых политик, которые можно привязывать как туннелям, так и к пользователям.
Наиболее удобной схемой использования этих политик, с учетом масштабирования в будущем, будет следующая схема:
Создаем настройку туннеля, определяющую ключ и созданный ранее пул адресов. Далее, создаем групповую политику, в которой описываем выдаваемые клиентам DNS-сервера, определяем возможность сохранения пароля в клиенте, доступ к локальной сети удаленного пользователя и другие параметры, имеющие прямое или косвенное отношение к возможностям удаленного пользователя. Далее. Создаем пользователя и привязываем его к политике.
Пошагово это выглядит следующим образом:
1. Настраиваем туннельную группу. Указываем, что туннельная группа будет использоваться для удаленного доступа, определяем пул адресов и указываем ключ шифрования. Единственное, что нужно продумать – это на название туннельной группы, так как она будет использоваться для подключения в виде имени пользователя в паре с ключом шифрования на первой фазе установления соединения. Также, здесь можно указать групповую политику, используемую этой туннельной группой, но этого мы делать не будем, так как в нашем случае удобней привязать групповую политику непосредственно пользователю:

Код: Выделить всё

tunnel-group remote type remote-access
tunnel-group remote general-attributes
 address-pool RAPool
tunnel-group remote ipsec-attributes
 pre-shared-key *
2. Следующий шаг – создание групповой политики. Здесь, в отличии от туннельной группы, название не принципиально, но лучше чтобы оно было понятным, и исходя из этого, я назвал групповую политику по имени пользователя, под которым будем подключаться. Интуитивно почти все параметры групповой политики ясны, кроме нескольких:
a. password-storage enable – разрешаем сохранение пароля в клиенте;
b. ipsec-udp enable – включаем инкапсуляцию IPSec в UDP дейтаграммы (нужно для клиентов, находящихся за NAT);
c. split-tunnel-policy tunnelspecified – определяем, каким образом будут настраиваться маршруты клиентов. В нашем случае, маршрут в сторону корпоративной сети будет включать только указанные соответствующей настройкой подсети;
d. split-tunnel-network-list value split-tunnel-ra – определяем, какие подсети будут маршрутизироваться через наш туннель. В качестве

Код: Выделить всё

split-tunnel-ra выступает Standart ACL.
access-list split-tunnel-ra standard permit 172.16.0.0 255.240.0.0
access-list split-tunnel-ra standard permit 10.101.224.0 255.255.255.0
group-policy RAdmin internal
group-policy RAdmin attributes
 wins-server value 172.16.9.3
 dns-server value 172.16.9.3 172.16.9.4
 password-storage enable
 ipsec-udp enable
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value split-tunnel-ra
 default-domain value DOMAIN
3. Далее, необходимо создать пользователя, под которым будем работать в корпоративной сети. Также, укажем, что пользователь используется для удаленного доступа и определяем для него групповую политику:

Код: Выделить всё

username RAdmin password ENCRYPTED_PASSWORD encrypted
username RAdmin attributes
 vpn-group-policy RAdmin
 service-type remote-access
На этом настройка удаленного доступа завершена. Настройка клиента достаточно проста. В настройках подключения используем удаленный адрес 1.1.1.1, в роли пользователя и ключа шифрования. Далее, при подключении к корпоративной сети будет необходимость ввести логин и пароль, которым соответствуют учетные данные пользователя RAdmin. Единственное что, при первом подключении не будет возможности сохранить пароль, она появится при последующих подключениях под данным пользователем. После удачного подключения необходимо зайти в статистику клиента и проверить маршруты на одноименной вкладке, где, в нашем случае, должно быть 2 маршрута на сети, указанные в ACL split-tunnel-ra.
Далее, для проверки работы туннеля попробуем попинговать узлы корпоративной сети и удаленного офиса. Результат должен быть не совсем положительным. Узлы корпоративной сети, которые находятся за inside интерфейсом PIX будут пинговаться, а вот что касается узлов удаленного офиса – они пинговаться не будут. Это происходит по той причине, что удаленный пользователь находится за интерфейсом outside, также, как и удаленный офис, а стандартное поведение Cisco PIX запрещает выход сетевого пакета из интерфейса, в который этот пакет вошел. Для исправления этой ситуации необходимо разрешить прохождение таких пакетов следующей командой:

Код: Выделить всё

same-security-traffic permit intra-interface
После ввода данной команды соединения между всеми тремя участниками (центральный офис, удаленный офис и удаленный пользователь) будут возможны.

Настроив и проверив VPN, перейдем к настройке демилитаризованной зоны. Для этого назначим сетевому интерфейсу, подключенному к ней, адрес 172.20.9.1/24 и определим уровень безопасности между уровнями безопасности inside и outside, например, 50. Это даст нам возможность контролировать соединения из демилитаризованной зоны во внутреннюю сеть, запретив их. Для всех взаимодействий между внутренней и удаленной сетей, и DMZ будем использовать технологию NAT.
На данный момент трансляция адресов выглядит следующим образом:

Код: Выделить всё

access-list pat-inside extended permit ip 172.16.9.0 255.255.255.128 any
access-list nonat-inside extended permit ip 172.16.0.0 255.240.0.0 172.25.9.0 255.255.255.0
access-list nonat-inside extended permit ip 172.16.0.0 255.240.0.0 172.26.9.0 255.255.255.0
access-list nonat-inside extended permit ip 10.101.224.0 255.255.255.0 172.25.9.0 255.255.255.0
access-list nonat-inside extended permit ip 10.101.224.0 255.255.255.0 172.26.9.0 255.255.255.0

global (outside) 1 1.1.1.2
nat-control
nat (inside) 0 access-list nonat-inside
nat (inside) 1 access-list pat-inside
Напомню, что данные настройки NAT предполагают динамическую трансляцию адрес-порт для внутренних узлов сети, что используется для подключения во внешние сети. А также, выключена трансляция адресов для пакетов, уходящих в сторону удаленного офиса.
Данные настройки не предполагают доступ в DMZ, так как трансляция для этой сети не настроена и включен nat-control, запрещающий форвардинг пакетов без настроенной трансляции адресов.
Казалось бы, настройка доступа в DMZ является тривиальной задачей, но и здесь есть свои подводные камни:
1. NAT Exception неприемлем, так как разрешает доступ в обе стороны;
2. Удаленные пользователи «приходят» с интерфейса outside, который имеет более низкий уровень безопасности, нежели DMZ, что позволит узлам из DMZ беспрепятственно слать пакеты в сторону удаленных офисов.
Для начала предоставим доступ внутренних узлов к DMZ. Оптимальным вариантов будет использование статической трансляции адресов внутренней сети (стоит обратить внимание на то, что используется вся подсеть 172.16.0.0/12, куда входят и удаленные пользователи). Данная настройка позволяет транслировать адреса внутренней сети в самих себя, что дает возможность производить подключения к узлам DMZ (ведь у нас включен nat-control, так что, трансляция в любом случае нужна):

Код: Выделить всё

static (inside,dmz) 172.16.0.0 172.16.0.0 netmask 255.240.0.0
Проверяем доступность узла в DMZ. Из внутренней сети он должен быть доступен.
Далее, необходимо настроить трансляцию узлов DMZ для удаленного офиса. На первый взгляд можно использовать статическую трансляцию:
static (dmz,outside) 172.20.9.0 172.20.9.0 netmask 255.255.255.0
При использовании такой настройки доступ к DMZ из удаленного офиса появится, но доступ из внешней сети настроить не удастся, так как мы транслируем внутренние адреса в самих себя, а о них внешний мир ничего не знает. Это уже сводит смысл такого DMZ к нулю. Для решения данной проблемы необходим избирательный подход для трансляции, то есть, нам нужно транслировать локальный адрес в локальный только для узлов удаленных офисов, которые знают где искать эти адреса. Делается это с помощью static policy nat, настройка которого выглядит следующим образом:
1. Определяем ACL, в котором в виде источника указываем адрес, в который нам необходимо транслировать адреса, а в качестве получателя – удаленные сети, для взаимодействия с которыми будет работать эта трансляция:

Код: Выделить всё

access-list static-nat-dmz extended permit ip 172.20.9.0 255.255.255.0 172.25.9.0 255.255.255.0
2. И создаем непосредственно трансляцию, где указываем для каких локальных адресов она будет создана и сам список доступа:

Код: Выделить всё

static (dmz,outside) 172.20.9.0  access-list static-nat-dmz
Проверяем доступность узлов DMZ со стороны внутренних узлов и со стороны узлов удаленного офиса. Узлы DMZ должны быть доступны.
Для верности проверим доступность узлов внутренней и удаленной сети со стороны узлов DMZ. Данные узлы не должны быть доступны. Ранее говорилось о проблеме уровня безопасности интерфейсов. Не смотря на теоретическое наличие этой проблемы, на практике ее не оказалось. Это связано с тем, что в трансляции адресов внутренней сети при подключении к DMZ мы указали всю сеть 172.16.0.0/12, в которые включаются также и адреса удаленных офисов. Таким образом, при попытке подключения из DMZ в подсеть удаленного офиса, PIX думает, что подключается к внутренней сети, и соответственно отбрасывает эти пакеты. Но при этом, когда пакет приходит с внешнего интерфейса (из удаленного офиса), он попадает в DMZ, так как подсеть DMZ транслируется наружу для подсети 172.25.9.0/24. В связи с этим получается, что мы добились нужного результата. Осталось раздать узлам DMZ интернет, если это необходимо и вывесить наружу необходимые службы:
1. Для раздачи интернета настроим динамический PAT, как и в случае с узлами внутренней сети, используя уже указанный ранее внешний адрес:

Код: Выделить всё

access-list pat-dmz extended permit ip 172.20.9.0 255.255.255.0 any
nat (dmz) 1 access-list pat-dmz
2. Настроим доступ к сетевым службам DMZ для внешней сети на примере службы TFTP:
a. Настроим статическую трансляцию порта в адрес:

Код: Выделить всё

static (dmz,outside) udp 1.1.1.3 tftp 172.20.9.10 tftp netmask 255.255.255.255
b. Разрешим входящие подключения на внешнем интерфейсе:

Код: Выделить всё

access-list outside extended permit udp any host 1.1.1.3 eq tftp
access-group outside in interface outside
Таким образом, настройка трансляции адресов выглядит следующим образом:

Код: Выделить всё

access-list outside extended permit udp any host 1.1.1.3 eq tftp
access-list pat-dmz extended permit ip 172.20.9.0 255.255.255.0 any
access-list pat-inside extended permit ip 172.16.9.0 255.255.255.128 any
access-list nonat-inside extended permit ip 172.16.0.0 255.240.0.0 172.25.9.0 255.255.255.0
access-list nonat-inside extended permit ip 172.16.0.0 255.240.0.0 172.26.9.0 255.255.255.0
access-list nonat-inside extended permit ip 10.101.224.0 255.255.255.0 172.25.9.0 255.255.255.0
access-list nonat-inside extended permit ip 10.101.224.0 255.255.255.0 172.26.9.0 255.255.255.0
access-list pat-dmz extended permit ip 172.20.9.0 255.255.255.0 any
nat-control
global (outside) 1 1.1.1.2
nat (inside) 0 access-list nonat-inside
nat (inside) 1 access-list pat-inside
nat (dmz) 1 access-list pat-dmz
static (dmz,outside) 172.20.9.0  access-list static-nat-dmz
static (dmz,outside) udp 1.1.1.3 tftp 172.20.9.10 tftp netmask 255.255.255.255
static (inside,dmz) 172.16.0.0 172.16.0.0 netmask 255.240.0.0
access-group outside in interface outside
На этом настройка Cisco PIX закончена. Но, необходимо иметь в виду, что доподлинно неизвестно (на сайте cisco.com не нашел подробной информации), в какой очередности используются правила NAT, следовательно, не исключена вероятность использования однотипных правил в порядке их следования в конфигурации. В нашем случае это может быть принципиально для правил трансляции адресов сети DMZ во внешнюю и удаленную сети. Если доступ в DMZ будет отсутствовать для одной из сетей, то имеет смысл поменять правила местами.


Использованная литература:
Frahim J., Santos O. - Cisco ASA. All-in-One Firewall, IPS, Anti-X, and VPN Adaptive Security Appliance, 2nd Edition, 2010
http://www.cisco.com/en/US/products/hw/ ... 4e8a.shtml
http://www.cisco.com/en/US/docs/securit ... nf_gd.html

Хостинговая компания Host-Food.ru
Хостинг HostFood.ru
 

Услуги хостинговой компании Host-Food.ru

Хостинг HostFood.ru

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

Аватара пользователя
Alex Keda
стреляли...
Сообщения: 35271
Зарегистрирован: 2004-10-18 14:25:19
Откуда: Made in USSR
Контактная информация:

Re: Статья: настройка DMZ и VPN на Cisco PIX 8.0(3)

Непрочитанное сообщение Alex Keda » 2013-01-23 14:10:24

блин, читал-читал - искал вопрос....
оказалось - инструкция =))
Убей их всех! Бог потом рассортирует...

GhOsT_MZ
лейтенант
Сообщения: 662
Зарегистрирован: 2011-04-25 11:40:35
Контактная информация:

Re: Статья: настройка DMZ и VPN на Cisco PIX 8.0(3)

Непрочитанное сообщение GhOsT_MZ » 2013-01-23 20:21:06

Да, инструкция, жаль что не актуальна по всей видимости...

Аватара пользователя
Alex Keda
стреляли...
Сообщения: 35271
Зарегистрирован: 2004-10-18 14:25:19
Откуда: Made in USSR
Контактная информация:

Re: Статья: настройка DMZ и VPN на Cisco PIX 8.0(3)

Непрочитанное сообщение Alex Keda » 2013-01-23 21:07:08

ну, как бе народ больше на тазиках чёнить изображает
Убей их всех! Бог потом рассортирует...