![[MARK logo]](http://www.mark-itt.ru/icons/mark_c4.gif){kind=icon}
Этот документ описывает использование виртуальных частных коммутируемых сетей - Virtual Private Dialup Network (VPDN).
Note:
Информацию о RFC упоминаемых в этом документе, смотрите: RFC поддерживаемые Cisco IOS Release 11.2; Комментарии к RFCs и другие документы о стандартах; или RFC Index для выхода на прямую к InterNIC.
Виртуальная частная коммутируемая сеть (Virtual Private Dialup Network (VPDN)) позволяет клиенту подключаться непосредственно к корпоративной ЛВС (к Серверу Доступа - NAS). Например, мобильные пользователи HEWLETT-PACKARD (типа комивояжеров) хотят иметь возможность подключаться к сети HEWLETT-PACKARD где угодно и когда угодно. HP заключил бы договор с поставщиком Internet-сервиса (Internet Service Providers (ISP)), который поддерживал бы VPDN. У этого провайдера должно быть настроено так, что если jsmith@hp.com позвонит на любой телефон провайдера, то NAS автоматически переправит его на локальный шлюз HP. ISP освобожден от управления IP адресами пользователей HP, маршрутизацией, и другими функциями, привязанными к базе пользователей HP. Администрирование провайдером уменьшено до обеспечения IP подключения к шлюзу HP.
Рисунок 1 описывает 'классический' путь, которым пользователь - jsmith - соединяется к NAS, чтобы подключится к внутреним сетям HP.
Рисунок 1: подключение jsmith к Серверу доступа
В терминологии VPDN, ISP является NAS и шлюз HP является шлюзом корпоративной ЛВС.
На Рисунке 2, показана PPP связь - между клиентом (jsmith) и корпоративным шлюзом. Распространение PPP соединения от NAS до корпоративного шлюза поддерживается протоколом L2F.
Рисунок 2: подключаение jsmith к шлюзу HP используя VPDN.
Следующие секции описывают некоторые аспекты L2F.
Здесь описываются перспективы PPP и L2F. Для более подробного изучения данного вопроса обратитесь к RFC L2F.
Последовательность начинается с описания поступающей PPP сессией на NAS от клиента. После фазы LCP обменов, начинается стадия PPP авторизации на NAS. NAS посылает CHAP запросы клиенту. Клиент, в свою очередь, возвращает CHAP ответ.
После получения этого ответа, NAS определяет соответствие имени пользователя конфигурации, по которой нужно использовать VPDN, чтобы переправить PPP-сессию на шлюз корпоративной сети. В этом случае, так как это первая L2F сессия к корпоративному шлюзу, NAS и локальный шлюз обмениваются пакетами L2F туннелирования. Именно на стадии L2F туннель между NAS и корпоративным шлюзом закончен. Когда L2F тунелирование закончено, NAS и корпоративный шлюз обмениваются пакетами(Mid) L2F сессии. Пакеты L2F_OPEN (Mid) от NAS Корпоративному шлюзу несут LCP информацию, CHAP запрос и ответ на него.
В корпоративном шлюзе LCP информация сессии LCP переправляется в виртуальный интерфейс доступа, созданный для L2F сессии. CHAP запрос и ответ заверяются корпоративным шлюзом. Например, послано CHAP сообщение: Auth-OK.
Поскольку, поскольку клиент авторизован, после получения ответа Auth-OK, PPP закончил стадию LCP авторизации. После этого возможен скрытый обменен между клиентом и корпоративным шлюзом. NAS невидим для PPP структуры.
Последующие сеансы PPP ( для того же самого шлюза) повторяют обмен сеанса L2F, т.к. уже существует L2F тунель, сформированный к корпоративному шлюзу.
Рисунок 3. PPP Aвторизация
Прежде, чем NAS и корпоративный шлюз открывают L2F туннель, каждый из них подтверждает подлинность другого. NAS посылает L2F_CONF, содержащий имя NAS и случайное число А. Когда корпоративный шлюз получает L2F_CONF, он посылает L2F_CONF назад NAS с именем корпоративного шлюза и случайным числом B. С этим сообщением к NAS передается ключ A' (MD5 кода NAS и значения A).
NAS, после получения L2F_CONF, сравнивает ключ A' с MD5 кода NAS и значения A. Если это соответствует, NAS посылает L2F_OPEN корпоративному шлюзу, на сей раз с ключом B' (MD5 кода корпоративного шлюза и значения B).
Корпоративный шлюз, после получения L2F_OPEN, сравнивает ключ B' с MD5 кода корпоративного шлюза и значения B. Если это соответствует, корпоративный шлюз посылает L2F_OPEN NAS с ключом A' .
Все последующие сообщения от NAS имеют ключ=B', все от корпоративного шлюза имеют ключ=A'.
Рисунок 4. Авторизация L2F туннелирования
Следующее - простая конфигурация для VPDN подключения. Клиент - "jsmith", NAS - "isp", и корпоративный шлюз - "hp-gw". Домен - "hp.com".
hostname jsmith@hp.com
! Username and password of NAS challenging this client
username isp password test
! VPDN NAS and Home Gateway secrets username hp-gw password hello username isp password there vpdn enable ! VPDN outgoing to hp-gw (1.1.1.2) vpdn outgoing hp.com isp ip 1.1.1.2
! VPDN NAS and Home Gateway secrets username hp-gw password hello username isp password there ! The client's username and secret username jsmith@hp.com password test vpdn enable !VPDN incoming from isp to (this) hp-gw. ! Use designated Virtual template vpdn incoming isp hp-gw virtual-template 1 !Virtual Template configuration int virtual-template 1 ip unum e0 encap ppp ppp authen chap
Если некоторые клиенты используют Multilink PPP (MP), а некоторые нет, то самая простая конфигурация должна быть готова к MP на NAS и Корпоратывном шлюзе. Обратите внимание, что нет никакой потребности определять команду виртуального шаблона MP.
! Set up for Straight PPP and Multilink on the PRI int serial0:23 ip address unum e0: encap ppp ppp authen chap ppp multilink
!VPDN incoming from isp to (this) hp-gw. ! Use designated Virtual template vpdn incoming isp hp-gw virtual-template 1
int virtual-template 1 ip unum e0 encap ppp ppp authen chap ppp multilink
По умолчанию, NAS вызывает клиента, клиент посылает ответ на NAS, который использует L2F, чтобы туннелировать опознавательную информацию корпоративному шлюзу, которым авторизация будет решена. Корпоративный шлюз не посылает CHAP запрос клиенту. Если требуется, чтобы был послан CHAP запрос от корпоративного шлюза, используется команда:
! Make the Home Gateway explicitly challenge the client vpdn force-local-chap
At the client, you will need to prepare for the CHAP challenge now arriving from hp-gw: Client jsmith@hp.com:
username hp-gw password test
Двунаправленный CHAP поддерживается в VPDN. Пример конфигурации (продолжение предыдущего):
Клиент jsmith@hp.com:
int s0 ppp authen chap
На NAS, AAA может использоваться, чтобы решить, использовать ли VPDN для специфического домена.
aaa new-model aaa authentication ppp default tacacs+ aaa authorization network tacacs+ local tacacs-server host 2.2.2.2 no tacacs-server directed-request tacacs-server key bulldog
user = hp.com {
service = ppp protocol = vpdn {
tunnel-id = isp
ip-addresses = "1.1.1.2"
nas-password = "hello"
gw-password = "there"
}
}
Последние две записи дополнительные. Они могли быть определены отдельно:
user = isp {
:
chap = cleartext "hello"
}
}
user = hp-gw {
:
chap = cleartext "there"
}
}
aaa new-model
aaa authentication ppp default tacacs+
aaa authorization network tacacs+ local
tacacs-server host 3.3.3.3
no tacacs-server directed-request
tacacs-server key unleash
TACAC+ записи:
user = isp {
:
chap = cleartext "hello"
}
}
user = hp-gw {
:
chap = cleartext "there"
}
}
user = jsmith@hp.com {
:
chap = cleartext "test"
}
}
aaa new-model aaa author network radius aaa authen ppp default radius local radius-server host 2.2.2.2 radius-server key malibu
Обратите внимание: Ключевое слово локальное для VPDN туннельной идентификации. Это - не обязательно при TACACS.
hp.com Password = "cisco", User-Service-Type = Outbound-User
cisco-avpair = "vpdn:tunnel-id=hp-gw",
cisco-avpair = "vpdn:ip-addresses=1.1.1.2",
cisco-avpair = "vpdn:nas-password=hello",
cisco-avpair = "vpdn:gw-password=there"
Последние два дополнительные записи. Они могли быть определены локально на NAS.
Эта опция позволяет NAS определить исходный IP-адрес NAS. Когда это определено, пакеты L2F к корпоративному шлюзу всегда имеют его как исходный IP-адрес.
#config vpdn vpdn source-ip 1.1.1.4
TBD
TBD
Эта опция позволяет выбрать VPDN туннель, в зависимости от набранного номера (Dialed Number Information (DNIS)) обеспеченный ISDN линиями или туннелированный модемами T1 (типа на AS5200). Например, если входящий номер, для соединения с NAS - 1234567:
#config vpdn outgoing dnis 1234567 isp ip 1.1.1.2
Вводится запись "dnis:1234567" (как, любое другое имя пользователя).
debug information:pdn event Se0:21 VPN got DNIS string 1234567 from ISDN
Обратите внимание: неявно что, если AAA не доступно или не соответствует для DNIS туннеля, VPDN будет искать любые существующие конфигурации VPDN на NAS для имени домена. Короче говоря, специфика DNIS предшествует общему соответствию для имени домена.
![[CISCO logo]](../../images/cisco.gif)
Коммуникационная компания
МАРК-ИТТ
Тел: +7 (3412) 430044; Факс: +7 (3412) 221365
E-mail: abon@mark-itt.ru