В терминологии VPDN, ISP является NAS и шлюз HP является шлюзом корпоративной ЛВС.
Следующие секции описывают некоторые аспекты L2F.
2.1 Поток L2F
Здесь описываются перспективы PPP и L2F. Для более подробного изучения данного вопроса обратитесь к RFC L2F.
2.1.1 PPP Авторизация
Последовательность начинается с описания поступающей 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 тунель, сформированный к корпоративному шлюзу.
2.1.2 Авторизация L2F туннелирования
3.0 Конфигурация VPDN
3.1 Простая конфигурация
Клиент jsmith:
! Username and password of NAS challenging this client
username isp password test
NAS isp:
Корпоративный шлюз hp-gw:
3.2 Конфигурирование Multilink PPP по VPDN
Если некоторые клиенты используют Multilink PPP (MP), а некоторые нет, то самая простая конфигурация должна быть готова к MP на NAS и Корпоратывном шлюзе. Обратите внимание, что нет никакой потребности определять команду виртуального шаблона MP.
NAS isp:
Корпоративный шлюз hp-gw:
Конфигурирование виртуального шаблона
3.3 CHAP авторизация с корпоративного шлюза
По умолчанию, NAS вызывает клиента, клиент посылает ответ на NAS, который использует L2F, чтобы туннелировать опознавательную информацию корпоративному шлюзу, которым авторизация будет решена. Корпоративный шлюз не посылает CHAP запрос клиенту. Если требуется, чтобы был послан CHAP запрос от корпоративного шлюза, используется команда:
Корпоративный шлюз hp-gw:
At the client, you will need to prepare for the CHAP challenge now arriving from hp-gw: Client jsmith@hp.com:
3.4 Двунаправленный CHAP
Двунаправленный CHAP поддерживается в VPDN. Пример конфигурации (продолжение предыдущего):
3.5 Пример конфигурации AAA (Authorization, and Accounting)
На NAS, AAA может использоваться, чтобы решить, использовать ли VPDN для специфического домена.
3.5.1 Используя TACACS+
NAS isp:
TACAC+ записи:
Последние две записи дополнительные. Они могли быть определены отдельно:
Корпоративный шлюз hp-gw:
3.5.2 Используя Radius
NAS isp:
Записи Radius:
Последние два дополнительные записи. Они могли быть определены локально на NAS.
3.6 Исходный адрес VPDN
Эта опция позволяет NAS определить исходный IP-адрес NAS. Когда это определено, пакеты L2F к корпоративному шлюзу всегда имеют его как исходный IP-адрес.
NAS isp:
3.7 Множественный адрес назначения VPDN
3.8 VPDN поверх Frame Relay
3.9 VPDN DNIS (Dialed Number Information Service )
NAS isp:
Используя TACACS+ или Radius:
Вводится запись «dnis:1234567» (как, любое другое имя пользователя).
Получение отладочной информации:
Обратите внимание: неявно что, если AAA не доступно или не соответствует для DNIS туннеля, VPDN будет искать любые существующие конфигурации VPDN на NAS для имени домена. Короче говоря, специфика DNIS предшествует общему соответствию для имени домена.
Поговорим о VPN-ах? Типы VPN соединений. Масштабирование VPN
Коллеги, здравствуйте. Меня зовут Семенов Вадим и я хочу представить статью, посвященную вопросу масштабируемости VPN-ов, причем тех VPN-ов, которые доступны для настройки в обычной корпоративной сети предприятия, а не со стороны провайдера. Надеюсь, данная статья станет справочным материалом, который может потребоваться при дизайне сети, либо при её апгрейде, либо для того, чтобы освежить в памяти принцип работы того или иного VPN-на.
В начале статьи описаны основные моменты стека протоколов IPSec, так как использование данного стандарта далее будет весьма часто встречаться. В конце параграфа об IPSec были включены самые частые причины неработоспособности IPSec канала, а также основные шаги по их устранению.
Типы VPN соединений
Ниже систематизированы VPN-ы, которые доступны для настройки в корпоративной сети. Технологии распределены по уровню предоставляемых клиенту каналов по модели OSI (рис 1):
Как раз VPN-ы для корпоративных сетей будут рассмотрены в данной статье.
Схема VPN-ов относительно возможности пропуска мультикаста и работы протоколов маршрутизации (рис. 2):
Дополнительно приводится структурированная схема VPN-ов (рис.3), которые могут предоставляться провайдером, но в данной статье подробно они не рассматриваются:
Итогом работы по систематизации VPN-ов и исследованию их масштабируемости послужила итоговая таблица, в которую заносилась общая информация по типу протокола VPN-а, его особенности, и самое важное, что необходимо сделать, если к существующим VPN-ам подключить еще один. В таблице представлены результаты настроек, исследование полученного формата пакета, настройка протокола маршрутизации (OSPF) через VPN-ы, а также рассмотрены вопросы масштабируемости протокола.
Таблица VPN
Тип VPN
Настройка HUB
Настройка Spoke
Настройка HUB при добавлении нового Spoke
Настройка Spoke при добавлении другого нового Spoke
Использование протоколов динамической маршрутизации OSPF, EIGRP
Особенности
Regular IPSec (crypto map)
isakmp Crypto-map
isakmp Crypto-map
Да: isakmp, crypto-map: set peer, transform-set, crypto ACL
Да: Для обеспечения связности между Spoke-ми необходимо добавить маршруты нового Spoke-a в crypto ACL всех существующих Spoke-ах
Нет
Удобен в случае кол-ва Spoke альтернатива L2TP over IPSec
L2TPv3 xconnect
pseudowire-class xconnect
pseudowire-class xconnect
Да xconnect
Нет
Да
Не масштабируемый. Отлично подходит для разнесения «native» L2 vlan-а через IP сеть. Но, необходимо наличие резервного шлюза по умолчанию. Создавая xconnect на интерфейсе маршрутизатора мы должны удалить IP адрес с его интерфейса, тем самым удалив маршрут по умолчанию для всех устройств внутри этой сети.
L2TPv2/v3
aaa new-model, username для авторизации L2TP пира, VPDN-group, interface Virtual-Template, static route до сетей уд. офиса
username для авторизации L2TP HUBa, interface virtual-ppp, pseudowire class, static route до сетей центр., удал. офиса
Да: static route до внутренних сетей удаленного офиса
Да: static route до внутренних сетей удаленного офиса
Да
Масштабируемый. L2TPv3 дает большие преимущества, позволяя инкапсулировать не только PPP трафик, как L2TPv2, но и передавать метку VLANа и, а также инкапсулировать HDLC, Frame Relay.
Очень масштабируемый. Позволяет настраивать протоколы маршрутизации «по умолчанию», связь удаленных офисов осуществляется через L2TPv2/v3 HUB (в центральном офисе).
Установление IPSec, сообщения, режимы работы.
В процессе установления соединения через IPSec двум участникам защищенного канала необходимо согласовать значительный ряд параметров: по необходимости они должны аутентифицировать друг друга, сгенерировать и обменяться общими ключами (причем через недоверенную среду), установить какой трафик шифровать (от какого отправителя и к какому получателю), а также договориться с помощью каких протоколов шифровать, а с помощью каких — аутентифицировать. Служебной информации предполагается обменяться много, не правда ли? По этой причине IPSec и состоит из стека протоколов, обязанность которых обеспечить установление, работу и управление защищенным соединением. Процесс установления соединения состоит из 2 фаз: первая фаза устанавливается для того, чтобы обеспечить безопасный обмен ISAKMP сообщений во второй фазе. А ISAKMP (Internet Security Association and Key Management Protocol) служит для согласования политик безопасности (SA) между участниками VPN соединения, в который как раз и определяются с помощью какого протокола шифровать (AES, 3DES, DES), и с помощью чего аутентифицировать (HMAC SHA, MD5).
Режим работы IKE (Internet Key Exchange):
IKE Фаза 1
IKE Фаза 1.5
IKE Фаза 2
IPsec SAs/SPIs На этом этапе ISAKMP ответственен за обмен сессионными ключами и согласование политик безопасности (SA) для обеспечения конфиденциальности и целостности пользовательского трафика. В настройке (в Cisco IOS) за это отвечает transform-set. Quick mode QM делает все то, что и IPSec SAs/SPIs за меньшее количество служебных сообщений. По аналогии с Aggressive Mode. Рассмотрим пример обмена служебными сообщениями во время установления IPSec туннеля. Работающий вариант.
ISAKMP:(1007):Old State = IKE_I_MM6 New State = IKE_I_MM6 *Sep 3 08:59:27.539: ISAKMP:(1007):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE *Sep 3 08:59:27.543: ISAKMP:(1007):Old State = IKE_I_MM6 New State = IKE_P1_COMPLETE
ФАЗА2
*Sep 3 08:59:27.559: ISAKMP:(1007):beginning Quick Mode exchange, M-ID of 2551719066 *Sep 3 08:59:27.563: ISAKMP:(1007):QM Initiator gets spi *Sep 3 08:59:27.575: ISAKMP:(1007): sending packet to 192.168.0.2 my_port 500 peer_port 500 (I) QM_IDLE *Sep 3 08:59:27.575: ISAKMP:(1007):Sending an IKE IPv4 Packet. *Sep 3 08:59:27.583: ISAKMP:(1007):Node 2551719066, Input = IKE_MESG_INTERNAL, IKE_INIT_QM *Sep 3 08:59:27.587: ISAKMP:(1007):Old State = IKE_QM_READY New State = IKE_QM_I_QM1
*Sep 3 08:59:27.803: ISAKMP:(1007):Checking IPSec proposal 1 *Sep 3 08:59:27.803: ISAKMP: transform 1, ESP_AES *Sep 3 08:59:27.807: ISAKMP: attributes in transform: *Sep 3 08:59:27.807: ISAKMP: encaps is 1 (Tunnel) *Sep 3 08:59:27.811: ISAKMP: SA life type in seconds *Sep 3 08:59:27.815: ISAKMP: SA life duration (basic) of 3600 *Sep 3 08:59:27.815: ISAKMP: SA life type in kilobytes *Sep 3 08:59:27.819: ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0 *Sep 3 08:59:27.827: ISAKMP: authenticator is HMAC-SHA *Sep 3 08:59:27.827: ISAKMP: key length is 128 *Sep 3 08:59:27.831: ISAKMP:(1007):atts are acceptable. *Sep 3 08:59:27.855: ISAKMP:(1007):Old State = IKE_QM_I_QM1 New State = IKE_QM_IPSEC_INSTALL_AWAIT ISAKMP:(1007):Old State = IKE_QM_IPSEC_INSTALL_AWAIT New State = IKE_QM_PHASE2_COMPLETE
А теперь я предлагаю рассмотреть пару примеров неработоспособности IPSec.
Case1
“Old State = IKE_I_MM1 New State = IKE_I_MM1” Причина №1 Не договорились по IKE proposal (предложенным IKE) в Фазе 1. На одной стороне указан 3des, на другом aes.
Error while processing SA request: Failed to initialize SA *Sep 3 08:36:38.239: ISAKMP: Error while processing KMI message 0, error 2. *Sep 3 08:36:38.287: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE. *Sep 3 08:40:38.307: ISAKMP (0): incrementing error counter on sa, attempt 3 of 5: retransmit phase 1 *Sep 3 08:40:38.307: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE *Sep 3 08:37:08.339: ISAKMP:(0):deleting SA reason «Death by retransmission P1» state (I) MM_NO_STATE (peer 192.168.0.2) *Sep 3 08:41:08.359: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL *Sep 3 08:41:08.359: ISAKMP:(0):Old State = IKE_I_MM1 New State = IKE_DEST_SA
На маршрутизаторе отображается следующее состояние:
R7#sh crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id status 192.168.0.2 192.168.0.1 MM_NO_STATE 0 ACTIVE
Причина №2 ACL на физическом интерфейсе блокируется трафик ISAKMP.
Case2
Case3
Если неправильно указали preshared key на IPSec пирах:
R7#sh run | i isakmp key crypto isakmp key cisco123 address 172.16.1.2
R10#sh run | i isakmp key crypto isakmp key cisco address 0.0.0.0 0.0.0.0
Тогда будет ошибка retransmitting phase 1 MM_KEY_EXCH
*Sep 3 09:14:30.659: ISAKMP:(1010): retransmitting phase 1 MM_KEY_EXCH. *Sep 3 09:14:30.663: ISAKMP (1010): incrementing error counter on sa, attempt 3 of 5: retransmit phase 1 *Sep 3 09:14:30.663: ISAKMP:(1010): retransmitting phase 1 MM_KEY_EXCH *Sep 3 09:14:30.663: ISAKMP:(1010): sending packet to 192.168.0.2 my_port 500 peer_port 500 (I) MM_KEY_EXCH *Sep 3 09:14:30.663: ISAKMP:(1010):Sending an IKE IPv4 Packet. *Sep 3 09:14:30.711: ISAKMP (1010): received packet from 192.168.0.2 dport 500 sport 500 Global (I) MM_KEY_EXCH *Sep 3 09:14:30.715: ISAKMP:(1010): phase 1 packet is a duplicate of a previous packet. *Sep 3 09:14:50.883: ISAKMP:(1011): retransmitting due to retransmit phase 1 *Sep 3 09:14:51.383: ISAKMP:(1011): retransmitting phase 1 MM_KEY_EXCH. *Sep 3 09:14:51.387: ISAKMP:(1011):peer does not do paranoid keepalives. *Sep 3 09:14:51.387: ISAKMP:(1011):deleting SA reason «Death by retransmission P1» state ® MM_KEY_EXCH (peer 192.168.0.2) *Sep 3 09:14:51.395: ISAKMP:(1011):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
Regular IPSec
Настройка через Crypto map
Конфигурация устройств:
HUB
Spoke1
Настройка первой фазы IPSec для обмена сессионного ключа:
crypto isakmp policy 1 hash md5 authentication pre-share group 5 crypto isakmp key cisco123 address 172.16.1.2 ! Настройка второй фазы IPSec c заданием алгоритма шифрования и аутентификации
crypto ipsec transform-set Trans_HUB1_SP1 esp-aes 256 esp-md5-hmac ! crypto map HUB_SPOKEs 1 ipsec-isakmp set peer 172.16.1.2 set transform-set Trans_HUB1_SP1 match address TO_Spoke1 reverse-route static !
local crypto endpt.: 172.16.1.2, remote crypto endpt.: 192.168.1.1 path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0 current outbound spi: 0xA7424886(2806139014) PFS (Y/N): N, DH group: none
SPI передается в IPSec пакете для того, чтобы при получении его пир-ом, в данном случае HUB-ом, HUB знал какой SA (security association) использовать, то есть какой протокол шифрования, какой протокол аутентификации и т.д. используется и как пакет расшифровывать. На HUB-е есть точно такая же SA с таким же SPI. Успешное прохождение трафика через VPN на HUB-e
HUB#sho crypto ipsec sa
interface: Ethernet0/0 Crypto map tag: HUB_SPOKEs, local addr 192.168.1.1
local crypto endpt.: 192.168.1.1, remote crypto endpt.: 172.16.1.2 path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0 current outbound spi: 0x10101858(269490264) PFS (Y/N): N, DH group: none
Теперь добавим еще один Spoke, посмотрим, какие изменения нам потребуется внести
Настройка на HUB
Настройка на новом Spoke
HUB# crypto isakmp policy 1 hash md5 authentication pre-share group 5 crypto isakmp key cisco123 address 172.16.1.2 crypto isakmp key cisco456 address 172.16.2.3 ! ! crypto ipsec transform-set Trans_HUB1_SP1 esp-aes 256 esp-md5-hmac ! crypto map HUB_SPOKEs 1 ipsec-isakmp set peer 172.16.1.2 set peer 172.16.2.3 set transform-set Trans_HUB1_SP1 match address TO_Spokes reverse-route static ! ip access-list extended TO_Spokes permit ip 10.0.0.0 0.0.0.255 1.1.1.0 0.0.0.255 permit ip 10.0.0.0 0.0.0.255 2.2.2.0 0.0.0.255
т.е. для добавленияNspoke-ов, нужно 3N дополнительный строчек
Настройка такая же как и на первом Spoke1 (с учетом поправки внутренних сетей в ACL) Spoke2# crypto isakmp policy 1 hash md5 authentication pre-share group 5 crypto isakmp key cisco456 address 192.168.1.1 ! ! crypto ipsec transform-set Trans_SP2_HUB1 esp-aes 256 esp-md5-hmac ! crypto map SP2_HUB 1 ipsec-isakmp set peer 192.168.1.1 set transform-set Trans_SP2_HUB1 match address TO_HUB reverse-route static ! ip access-list extended TO_HUB permit ip 2.2.2.0 0.0.0.255 10.0.0.0 0.0.0.255
Проверка работы VPN
Проверка доступности второго удаленного офиса: HUB#ping 2.2.2.2 source 10.0.0.1 . Success rate is 80 percent (4/5), round-trip min/avg/max = 4/4/5 ms
На HUBе теперь появилась дополнительная сессия обмена ключами со вторым Spoke: HUB#sho crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id status 192.168.1.1 172.16.2.3 QM_IDLE 1009 ACTIVE 192.168.1.1 172.16.1.2 QM_IDLE 1008 ACTIVE
Однако связи между офисами нет (даже через HUB). Spoke1#ping 2.2.2.2 source 1.1.1.1 . Success rate is 0 percent (0/5)
Отсутствие связности до Spoke2 неудивительно — необходимо включать внутренние сети нового удаленного офиса в Crypto ACL, в итоге для обеспечения связности между Spokе-ми через HUB требуется добавление в Crypto ACL N сетей на N spoke-ах.
Альтернатива. Множественные Crypto map.
Пример конфигурации IPSec множественных VPN-ов с удаленными офисами с динамическими или статическими ip адресами, когда каждый офис получает доступ через интернет канал VPN-HUBа, но при этом все удаленные сети находятся в таблице маршрутизации и до них организована связь без использования NAT-а.
Настройка через Virtual Tunnel Interface + профайлы.
Проверка установления соседства через OSPF over Static VTI
HUB#sh ip ospf neighbor
Сеть наSpoke 1 теперь доступна через туннель HUB#sh ip route 1.0.0.0/32 is subnetted, 1 subnets O 1.1.1.1 [110/1001] via 10.1.1.1, 00:02:56, Tunnel0 10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks C 10.0.0.0/24 is directly connected, Loopback0 L 10.0.0.1/32 is directly connected, Loopback0 C 10.0.1.0/24 is directly connected, Loopback1 L 10.0.1.1/32 is directly connected, Loopback1 C 10.1.1.0/24 is directly connected, Tunnel0 L 10.1.1.254/32 is directly connected, Tunnel0
Проверка доступности сетей в Центральном офисе соSpoke 1 Spoke1#ping 10.0.0.1 source 1.1.1.1 . Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/5 ms
Traffic Selector для Static VTI ip any any, т.е. все, что мы направим в туннель через статический маршрут либо через протокол маршрутизации, то и будет шифроваться/дешифроваться.
interface Tunnel0 ip address 10.1.1.254 255.255.255.0 ip ospf mtu-ignore
OSPF Neighbor осуществляет проверку на использование одинакового значения MTU на интерфейсе. Если neighbor получит размер MTU в DBD пакете бОльший, чем MTU своего входящего интерфейса, то соседство не установится. При подключении второго Spoke2 настраивается второй Tunnel (HUB-Spoke2), на которого выделяется своя отдельная подсеть.
HUB#sho ip ospf neighbor
Маршруты на Spoke1 Spoke1#sh ip route Gateway of last resort is 172.16.1.5 to network 0.0.0.0
Связка туннельного адреса и реального (физического) HUB#sh ip nhrp brief Target Via NBMA Mode Intfc Claimed 10.5.5.1/32 10.5.5.1 172.16.1.2 dynamic Tu1 10.5.5.2/32 10.5.5.2 172.16.2.3 dynamic Tu1
Создание динамического GRE туннеля от удаленного офиса Spoke1 к Spoke2 Вначале загрузки у Spoke 1 был только 1 туннель до HUBа. При генерировании трафика (пинга) до Spoke2, сразу же создался туннель до Spoke2
Router#ping 10.5.5.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.5.5.2, timeout is 2 seconds: . Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/5 ms
На данный момент схема сети (рис.13) будет уже выглядеть так:
Динамические протоколы маршрутизации через DMVPN
Настройка OSPF
Сделав настройки по DMVPN и включив общую сеть для VPN-а 10.5.5.0 в процесс OSPF – мы будем наблюдать как OSPF на HUBе будет устанавливать смежные отношения сначала со Spoke1 до того момента, как не получит hello пакет со Spoke2, после этого отношения рушатся с ошибкой Neighbor Down: Adjacency forced to reset, так как по умолчанию interface Tunnel выставлен как point-to-point интерфейс. Для корректной работы OSPF необходимо выставить network type как broadcast. Если выставить broadcast только на HUBe, то соседства установятся, но маршрутов через OSPF на Spok-aх не будет, поэтому необходимо выставить broadcast и на HUB, и на Spoke-ах. Ниже приведены таблицы поведения OSPF в зависимости от выбранного значения network type.
HUB
Spoke 1
Spoke 2
BROADCAST
BROADCAST
BROADCAST
HUB#sh ip ospf neighbor
Neighbor I Pri State Dead Time Address Interface 1.1.1.1 0 FULL/DROTHER 00:00:34 10.5.5.1 Tunnel1 2.2.2.2 0 FULL/DROTHER 00:00:31 10.5.5.2 Tunnel1
Spoke_1#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface 10.0.0.1 1 FULL/DR 00:00:36 10.5.5.254 Tunnel1
Spoke_1#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface 10.0.0.1 1 FULL/DR 00:00:36 10.5.5.254 Tunnel1
Известные маршруты на Spoke 1 через OSPF Spoke_1#sh ip route
Gateway of last resort is 172.16.1.5 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 172.16.1.5 1.0.0.0/32 is subnetted, 1 subnets C 1.1.1.1 is directly connected, Loopback1 2.0.0.0/32 is subnetted, 1 subnets O 2.2.2.2 [110/1001] via 10.5.5.3, 00:00:07, Tunnel1 Spoke2
HUB (R1)
Spoke (R3)
Spoke (R4)
HUB(conf)# router eigrp 1 no ip split-horizon eigrp 1 no ip next-hop-self eigrp 1
Нет доп.настройки
Нет доп.настройки
Теперь маршрут до сети Spoke_2 ведет напрямую: R3#sh ip route eigrp 1 D 1.0.0.0/8 [90/324096] via 10.5.5.1, 00:00:06, Tunnel4 3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks D 3.0.0.0/8 is a summary, 00:00:06, Null0 D 4.0.0.0/8 [90/435200] via 10.5.5.4, 00:00:04, Tunnel4 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks D 10.0.0.0/8 is a summary, 00:19:55, Null0
R3#traceroute 4.4.4.4 source 3.3.3.3
Type escape sequence to abort. Tracing the route to 4.4.4.4 1 10.5.5.4 84 msec * 72 msec
PPTP стал совместной разработкой консорциумов Microsoft, 3Com, Ascend Communication. Хорошо масштабируемый протокол. Может использоваться для соединения офисов по типу точка-точка, но, больше всего подходит для организации удаленного подключения по архитектуре клиент-сервер. Достаточно настроить центральный PPTP VPN HUB, а удаленные пользователи подключаются через PPTP клиент, который внедрен во всех OC Windows, в том числе MacOS и Linux-дистрибутивах. Существуют криптографические проблемы в протоколе аутентификации MSCHAPv2 [https://technet.microsoft.com/ru-ru/library/security/2743314.aspx], поэтому в большинстве случаев рекомендовано использование даже на той же самой OC Windows протокола L2TP over IPSec вместо PPTP. В качестве средств шифрования используется только один протокол шифрования Microsoft Point-to-Point Encryption (128битный ключ), в качестве аутентификации – MSCHAPv2, PEAP (рекомендовано). PPTP в процессе своей работы устанавливает 2 сессии: PPP сессию с использованием GRE протокола и TCP соединение по порту 1723 для обслуживания PPTP сессии. Установление TCP сессии перед установлением PPP соединения
Формат PPP пакета (рис.15)
PPTP_HUB # Username cisco2 password cisco2 ! interface Loopback1 ip address 192.168.2.2 255.255.255.0 ! vpdn enable ! vpdn-group 1 ! Default PPTP VPDN group accept-dialin protocol pptp virtual-template 1 ! interface Virtual-Template1 ip unnumbered Loopback1 ip mtu 1400 ip tcp adjust-mss 1360 peer default ip address pool PPTP-Pool ppp encrypt mppe auto ppp authentication ms-chap-v2 chap callin ! ip local pool PPTP-Pool 192.168.2.5 192.168.2.50 !
Проверка установленных PPTP соединений. Пользователь cisco2 авторизован и сессия установлена.
PPTP_HUB #sho vpdn session %No active L2TP tunnels PPTP Session Information Total tunnels 1 sessions 1 LocID RemID TunID Intf Username State Last Chg Uniq ID 55592 0 17168 Vi3 cisco2 estabd 00:04:13 6
Пользователю выдан ip адрес из DHCP Pool-а и создан virtual-access
PPTP_HUB#sh ip int br Interface IP-Address OK? Method Status Protocol Ethernet0/0 unassigned YES NVRAM administratively down down GigabitEthernet0/0 192.168.1.3 YES NVRAM up up GigabitEthernet1/0 77.1.1.3 YES NVRAM up up Loopback0 3.3.3.3 YES NVRAM up up Loopback1 192.168.2.2 YES NVRAM up up Virtual-Access1 unassigned YES unset down down Virtual-Access2 unassigned YES unset up up Virtual-Access3 192.168.2.5 YES unset up up Virtual-Template1 192.168.2.5 YES unset down down
В случае если возникает задача конкретному PPTP клиенту выдавать принадлежащий только ему IP адрес, то тогда можно прибегнуть к созданию TXT файла с перечислением всех PPTP клиентов. Настройка на маршрутизаторе:
ip dhcp pool STATIC import all origin file flash:/static2.txt default-router 192.168.2.2 dns-server 8.8.8.8 8.8.4.4 domain-name lab.local lease 3 ! interface Virtual-Template1 ip unnumbered Loopback1 ip mtu 1400 ip tcp adjust-mss 1360 peer default ip address pool STATIC (PPTP-Pool нам уже не нужен) ppp encrypt mppe auto ppp authentication ms-chap-v2 chap callin
Сам TXT файлик static2.txt.
*time* Mar 01 2002 12:23 AM *version* 2 !IP address Type Hardware address Lease expiration VRF 192.168.2.77 /25 1000c.2984.4f84 Infinite 192.168.2.17 /25 1000c.2946.1575 Infinite 192.168.2.18 /25 10000.0000.1111 Infinite
L2TP – это стандарт IETF, который вобрал в себя лучшее от протокола L2F от Cisco и PPTP от Microsoft. Не предлагает средств по защите данных, поэтому часто используется с IPSec.
Главное отличие L2TPv3 перед L2TPv2 это то, что L2TPv3 может туннелировать различный тип трафика (см. выше), в то время как v2 только PPP.
L2TPv2 инкапсулирует данные в IP/UDP (UDP порт 1701).
IP_add_s_global IP_add_d_global
UDP_s_port UDP_d_port(1701)
L2TP_header
PPP_header
IP_add_s_local IP_add_d_local
Data
L2TPv3 Pseudowire
В архитектуре L2TP, равно как и в архитектуре PPTP, используются следующие понятия:
LAC
L2TP access concentrator
LAC принимает на себя запросы от клиента и согласует L2TP параметры туннелей и сессий с LNS и передает запрос LNS
LNS
L2TP network server
LNS согласует L2TP параметры туннелей и сессий с LAC
LCCE
L2TP Control Connection Endpoint
Это LAC, который участвует в сигнальном соединении.
Модель работы протоколов для L2TPv3 LNS – LNS, а для L2TPv2 LAC – LNS (подробнее см.ниже). Создадим pseudowire между R5 в Центральном офисе и в R9 в региональном офисе, тем самым расширим сеть 192.168.1.x/24 в региональный офис.
R5# pseudowire-class L2TP_Class encapsulation l2tpv3 protocol none (то есть не используется динамическое установление сессии) ip pmtu ip local interface GigabitEthernet1/0 ! interface GigabitEthernet0/0 no ip address xconnect 44.1.1.9 1 encapsulation l2tpv3 manual pw-class L2TP_Class l2tp id 1 2 l2tp cookie local 4 55111 l2tp cookie remote 44119
R9# pseudowire-class L2TP_Class encapsulation l2tpv3 protocol none (то есть не используется динамическое установление сессии) ip pmtu ip local interface GigabitEthernet0/0 ! interface GigabitEthernet1/0 no ip address xconnect 55.1.1.1 1 encapsulation l2tpv3 manual pw-class L2TP_Class l2tp id 2 1 l2tp cookie local 4 44119 l2tp cookie remote 4 55111
Проверка установления сессии:
R5_VPN_HUB_Pr#sh l2tp session
L2TP Session Information Total tunnels 0 sessions 1
LocID RemID TunID Username, Intf/ State Last Chg Uniq ID Vcid, Circuit 1 2 n/a 1, Gi0/0 est 00:00:03 1
R5_VPN_HUB_Pr#sh l2tp session all
L2TP Session Information Total tunnels 0 sessions 1
Session id 1 is up, logical session id 33356, tunnel id n/a Remote session id is 2, remote tunnel id n/a Locally initiated session Unique ID is 4 Session Layer 2 circuit, type is Ethernet, name is GigabitEthernet0/0 Session vcid is 1 Circuit state is UP Local circuit state is UP Remote circuit state is UP Call serial number is 0 Remote tunnel name is Internet address is 44.1.1.9 Local tunnel name is Internet address is 55.1.1.5 IP protocol 115 Session is manually signaled Session state is established, time since change 02:29:58 1130 Packets sent, 1982 received 151213 Bytes sent, 197759 received Last clearing of counters never
R7 теперь доступен без протоколов маршрутизации:
R10#ping 192.168.1.7 repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 192.168.1.7, timeout is 2 seconds: . Success rate is 100 percent (10/10), round-trip min/avg/max = 128/142/180 ms
Работа OSPF через L2TP
Соседство установилось по умолчанию, включив сеть 192.168.1.0 на R7 и R10
R7_DATA_Center_Servers#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface 192.168.1.10 1 FULL/DR 00:00:37 192.168.1.10 GigabitEthernet0/0
R10#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface 7.7.7.7 1 FULL/BDR 00:00:35 192.168.1.7 GigabitEthernet0/0
В добровольном /клиентском инициированном туннеле удаленный хост действует как LAC, то есть он согласует и устанавливает L2TP сессию непосредственно с LNS.
В нашем примере Cisco R9 (44.1.1.9) будет действовать как LAC и устанавливать L2TP соединение с Cisco R5 в ЦОДе (55.1.1.1), которая будет выступать в роли LNS.
*Oct 20 19:52:55.861: L2X tnl 08287:________: Create logical tunnel *Oct 20 19:52:55.865: L2TP tnl 08287:________: Create tunnel *Oct 20 19:52:55.869: L2TP tnl 08287:________: version set to V2 (протоколL2TPv2) *Oct 20 19:52:55.873: L2TP tnl 08287:________: remote ip set to 44.1.1.9 *Oct 20 19:52:55.873: L2TP tnl 08287:________: local ip set to 55.1.1.1 *Oct 20 19:52:55.877: L2TP tnl 08287:00003073: FSM-CC ev Rx-SCCRQ (Start—Control—Connection—Request)LNSпроверяет валидность отправителя и наличие собственных ресурсов, также на этом этапе согласуется список поддерживаемых типовpseudowire(Ethernet,FrameRelay) *Oct 20 19:52:55.877: L2TP tnl 08287:00003073: FSM-CC Idle->Proc-SCCRQ *Oct 20 19:52:55.877: L2TP tnl 08287:00003073: FSM-CC do Rx-SCCRQ *Oct 20 19:52:55.881: L2X _____:________: Tunnel author started for LAC *Oct 20 19:52:55.901: L2X _____:________: Tunnel author found *Oct 20 19:52:55.905: L2TP tnl 08287:00003073: Author reply, data source: «VPDN-L2TP» *Oct 20 19:52:55.909: L2X _____:________: class [AAA author, group «VPDN-L2TP»] *Oct 20 19:52:55.913: L2X _____:________: created *Oct 20 19:52:55.917: L2TP tnl 08287:00003073: FSM-CC ev SCCRQ-OK *Oct 20 19:52:55.917: L2TP tnl 08287:00003073: FSM-CC Proc-SCCRQ->Wt-SCCCN Start-Control-Connection-Connected (SCCCN)ожидаемсостоянияConnected *Oct 20 19:52:55.917: L2TP tnl 08287:00003073: FSM-CC do Tx-SCCRP Start-Control-Connection-Reply (SCCRP)отправилиответноесообщение *Oct 20 19:52:55.917: L2X _____:________: l2x_open_socket: is called *Oct 20 19:52:55.921: L2TP tnl 08287:00003073: Open sock 55.1.1.1:1701->44.1.1.9:1701 ИспользуетсяUDP с портом 1701 для служебных сообщений *Oct 20 19:52:55.925: L2TP tnl 08287:00003073: FSM-CC ev Sock-Ready *Oct 20 19:52:55.929: L2TP tnl 08287:00003073: FSM-CC in Wt-SCCCN *Oct 20 19:52:55.929: L2TP tnl 08287:00003073: FSM-CC do Ignore-Sock-Up *Oct 20 19:52:55.941: L2X _____:________: Disabled security for VPDN *Oct 20 19:52:56.053: L2TP tnl 08287:00003073: FSM-CC ev Rx-SCCCN *Oct 20 19:52:56.053: L2TP tnl 08287:00003073: FSM-CC Wt-SCCCN->Proc-SCCCN *Oct 20 19:52:56.053: L2TP tnl 08287:00003073: FSM-CC do Rx-SCCCN *Oct 20 19:52:56.053: L2TP tnl 08287:00003073: Got a response in SCCCN from LAC *Oct 20 19:52:56.057: L2TP tnl 08287:00003073: Tunnel Authentication success *Oct 20 19:52:56.061: L2TP tnl 08287:00003073: FSM-CC ev SCCCN-OK *Oct 20 19:52:56.065: L2TP tnl 08287:00003073: FSM-CC Proc-SCCCN->established *Oct 20 19:52:56.069: L2TP tnl 08287:00003073: FSM-CC do Established *Oct 20 19:52:56.073: L2TP tnl 08287:00003073: Control channel up *Oct 20 19:52:56.077: L2TP tnl 08287:00003073: 55.1.1.1 44.1.1.9
Служебный канал установился, теперь устанавливается канал для данных (PPP фреймов). Стоит отметить, что по одному установившемуся туннелю может проходить множество клиентских сессий.
Для установки сессии для данных LAC отправляет ICRQ (Call-Request), если на LNS достаточно ресурсов, то LNS отвечает сообщением ICRP (Call-Reply). Для завершения установления сессии – LAC отправляет ICCN Incoming-Call-Connected.
*Oct 20 19:52:56.117: L2X _____:_____:________: Create logical session *Oct 20 19:52:56.121: L2TP _____:_____:________: Create session *Oct 20 19:52:56.121: L2TP _____:_____:________: Using ICRQ FSM Incoming-Call-Request (ICRQ)Здесьпередаетсятребуемыйpseudowireтип,требуемыйдляуровняL2 *Oct 20 19:52:56.125: L2TP _____:_____:________: remote ip set to 44.1.1.9 *Oct 20 19:52:56.125: L2TP _____:_____:________: local ip set to 55.1.1.1 *Oct 20 19:52:56.129: L2TP tnl 08287:00003073: FSM-CC ev Session-Conn *Oct 20 19:52:56.129: L2TP tnl 08287:00003073: FSM-CC in established *Oct 20 19:52:56.129: L2TP tnl 08287:00003073: FSM-CC do Session-Conn-Est *Oct 20 19:52:56.129: L2TP tnl 08287:00003073: Session count now 1 *Oct 20 19:52:56.129: L2TP _____:08287:0000754C: Session attached *Oct 20 19:52:56.129: L2TP _____:08287:0000754C: FSM-Sn ev Rx-ICRQ *Oct 20 19:52:56.129: L2TP _____:08287:0000754C: FSM-Sn Idle->Proc-ICRQ *Oct 20 19:52:56.129: L2TP _____:08287:0000754C: FSM-Sn do Rx-ICRQ *Oct 20 19:52:56.129: L2TP _____:08287:0000754C: Chose application VPDN *Oct 20 19:52:56.133: L2TP _____:08287:0000754C: App type set to VPDN *Oct 20 19:52:56.133: L2TP tnl 08287:00003073: VPDN Session count now 1 *Oct 20 19:52:56.189: L2TP 00005:08287:0000754C: FSM-Sn ev ICRQ-OK *Oct 20 19:52:56.193: L2TP 00005:08287:0000754C: FSM-Sn Proc-ICRQ->Wt-Tx-ICRP *Oct 20 19:52:56.193: L2TP 00005:08287:0000754C: FSM-Sn do Tx-ICRP-Local-Check *Oct 20 19:52:56.193: L2TP 00005:08287:0000754C: FSM-Sn ev Local-Cont *Oct 20 19:52:56.193: L2TP 00005:08287:0000754C: FSM-Sn Wt-Tx-ICRP->Wt-Rx-ICCN *Oct 20 19:52:56.193: L2TP 00005:08287:0000754C: FSM-Sn do Tx-ICRP Incoming-Call-Reply (ICRP) *Oct 20 19:52:56.197: L2TP 00005:08287:0000754C: Open sock 55.1.1.1:1701->44.1.1.9:1701 *Oct 20 19:52:56.197: L2TP 00005:08287:0000754C: FSM-Sn in Wt-Rx-ICCN (ожидаемICCN) *Oct 20 19:52:56.397: L2TP 00005:08287:0000754C: FSM-Sn ev Rx-ICCN (ICCNполучили) *Oct 20 19:52:56.401: L2TP 00005:08287:0000754C: FSM-Sn Wt-Rx-ICCN->Proc-ICCN *Oct 20 19:52:56.405: L2TP 00005:08287:0000754C: FSM-Sn do Rx-ICCN *Oct 20 19:52:56.437: L2TP 00005:08287:0000754C: FSM-Sn ev ICCN-OK *Oct 20 19:52:56.441: L2TP 00005:08287:0000754C: FSM-Sn Proc-ICCN->established *Oct 20 19:52:56.445: L2TP 00005:08287:0000754C: FSM-Sn do Established *Oct 20 19:52:56.449: L2TP 00005:08287:0000754C: Sessionup (Ceccия для данных установилась) *Oct 20 19:52:58.197: L2TP 00005:08287:0000754C: FSM-Sn in established *Oct 20 19:52:58.241: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up *Oct 20 19:52:58.273: %LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up
В нашем примере сформировался один туннель между LAS и LNS и одна пользовательская сессия.
ISP_NAT#sh l2tun tunnel L2TP Tunnel Information Total tunnels 1 sessions 1 LocTunID RemTunID Remote Name State Remote Address Sessn L2TP Class/ Count VPDN Group 30933 12403 LNS est 55.1.1.1 1 1
Настройка L2TPv2
На некоторых типах маршрутизаторов нельзя создать interface virtual-ppp, поэтому привожу в качестве альтернативны другую рабочую конфигурацию через создание interface Dialer. Конфигурация предоставляется «AS IS».
LNS# aaa new-model aaa authorization network default local ! vpdn enable vpdn-group VPDN-L2TP accept-dialin protocol l2tp virtual-template 2 lcp renegotiation on-mismatch terminate-from hostname LAC l2tp tunnel password 0 cisco123 ip pmtu ! interface Virtual-Template2 ip unnumbered GigabitEthernet0/0 autodetect encapsulation ppp peer default ip address pool L2TP-pool ppp authentication ms-chap-v2
LAC# vpdn enable ! vpdn-group 1 request-dialin protocol l2tp pool-member 1 initiate-to ip 55.1.1.1 source-ip 44.1.1.9 local name LAC (имя должно совпадать с terminate-from на LNS) l2tp tunnel password 0 cisco123 ! interface Dialer1 ip address negotiated encapsulation ppp dialer pool 1 dialer idle-timeout 0 dialer string 123 dialer vpdn dialer-group 1 ppp authentication chap callin ppp chap hostname LNC ppp chap password 0 cisco123 ! ip route 192.168.1.0 255.255.255.0 Dialer1
Конфигурация L2TPv2 через interface virtual-ppp
LNS# aaa new-model ! aaa authorization network default local ! username LAC password 0 cisco123 ! vpdn enable vpdn-group VPDN-L2TP accept-dialin protocol l2tp virtual-template 2 terminate-from hostname LAC l2tp tunnel password 0 cisco123 ! interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! interface Virtual-Template2 ip unnumbered Loopback0 autodetect encapsulation ppp no peer default ip address ppp authentication ms-chap-v2 ! ip route 172.30.1.0 255.255.255.0 7.7.7.7 ! добавляем статический маршрут до сети удаленного офиса R7
(P.S. маршрут до 7.7.7.7 добавляется автоматически при установлении сессии LNS#show ip route 7.0.0.0/32 is subnetted, 1 subnets C 7.7.7.7 is directly connected, Virtual-Access3 )
LAC# username LNS password 0 cisco123 ! l2tp-class client.init.class authentication password cisco123 ! pseudowire-class pwclass1 encapsulation l2tpv2 protocol l2tpv2 client.init.class ip local interface Ethernet0/0 ! interface Loopback0 ip address 7.7.7.7 255.255.255.255 ! interface Virtual-PPP1 ip unnumbered loopback0 ppp authentication ms-chap-v2 no cdp enable pseudowire 55.1.1.3 1 pw-class pwclass1 ! ip route 192.168.1.0 255.255.255.0 Virtual-PPP1 ! добавляем статический маршрут до ЦО
(P.S. маршрут до 3.3.3.3 добавляется автоматически при установлении сессии 3.0.0.0/32 is subnetted, 1 subnets C 3.3.3.3 is directly connected, Virtual-PPP1 )
Проверка установления туннеля и заодно проверяем работу сессии через пинг с внутренней сети удаленного клиента (LAC) и просмотра статистики сессионных пакетов на L2TP HUBe (LNS)
LNS#show vpdn L2TP Tunnel and Session Information Total tunnels 1 sessions 1 LocTunID RemTunID Remote Name State Remote Address Sessn L2TP Class/ Count VPDN Group 6022463290 LAC est 77.1.1.7 1 VPDN-L2TP
LocID RemID TunID Username, Intf/ State Last Chg Uniq ID Vcid, Circuit 46580 40688 60224 LAC, Vi3 est 00:14:12 102
LAC#sho vpdn L2TP Tunnel and Session Information Total tunnels 1 sessions 1 LocTunID RemTunID Remote Name State Remote Address Sessn L2TP Class/ Count VPDN Group 63290 60224 LNS est 55.1.1.3 1 client.init.cla
LocID RemID TunID Username, Intf/ State Last Chg Uniq ID Vcid, Circuit 40688 46580 63290 1, Vp1 est 00:20:54 8
OSPF работает словно через broadcast сеть LNS# router ospf 1 network 3.3.3.3 0.0.0.0 area 0 network 192.168.1.0 0.0.0.255 area 0 default-information originate always
Объявим сеть 3.3.3.3 в ospf area 0 LAC# interface Loopback1 ip address 77.77.77.77 255.255.255.255 ! router ospf 1 network 3.3.3.3 0.0.0.0 area 0 network 77.77.77.77 0.0.0.0 area 0
LSA протокола OSPF через L2TPv2 Обратите, пожалуйста, внимание на получившийся overhead.
Протокол L2TP не обеспечивает защищенность передаваемых по нему данных, поэтому для обеспечения целостности и конфиденциальности данных используем набор протоколов IPSec. Из средств безопасности L2TP может предложить аутентификацию хоста, инициализирующего туннель, а также PPP аутентификацию. Так как в нашем примере использован протокол L2TPv2, который использует IP/UDP инкапсуляцию, то достаточно в крипто ACL определить лишь UDP трафик по порту 1701. В настройке IPSec используется транспортный режим, а не туннельный, чтобы шифровать трафик от оконечного клиента оконечному (в транспортном режиме), нежели создавать дополнительные IP туннельные интерфейсы и шифровать трафик только между ними (в туннельном режиме).
Схема сети:
LNS# crypto isakmp policy 10 encr 3des authentication pre-share group 2 ! crypto isakmp key ipseckey123 address 77.1.1.7 ! crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac mode transport ! crypto map L2TP_VPN 10 ipsec-isakmp set peer 77.1.1.7 set transform-set ESP-AES256-SHA1 match address L2TP_TRAFFIC ! ! Так как мы используем L2TPv2, то достаточно! определить для шифрования весь UDP трафик! по порту 1701 ip access-list extended L2TP_TRAFFIC permit udp host 55.1.1.3 eq 1701 host 77.1.1.7 eq 1701 ! interface Ethernet0/1 ip address 55.1.1.3 255.255.255.0 crypto map L2TP_VPN
Соседство через OSPF не было потеряно, hello пакеты по-прежнему приходят через каждый 10 сек. Маршруты анонсируются через удаленный OSPF соседний маршрутизатор.
LNS#sh ip ospf neighbor
LNS#sh ip route C 7.7.7.7 is directly connected, Virtual-Access3 O 77.77.77.77/32 [110/2] via 7.7.7.7, 21:54:59, Virtual-Access3 172.30.0.0/24 is subnetted, 1 subnets S 172.30.1.0 [1/0] via 7.7.7.7 192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
Масштабирование. Подключение нового удаленного офиса через L2TPv2
Настройка для LNS, т.е. для L2TPv2 HUBа минимальная – необходимо лишь добавить пользователя для PPP CHAP авторизации. Если этого не сделать, то будет следующая ошибка:
LAC_9# username LNS password 0 cisco123 ! l2tp-class client.init.class authentication password cisco123 ! pseudowire-class pwclass1 encapsulation l2tpv2 protocol l2tpv2 client.init.class ip local interface Ethernet0/0 ! interface Loopback0 ip address 9.9.9.9 255.255.255.255 ! interface Virtual-PPP1 ip address loopback0 ppp authentication ms-chap-v2 no cdp enable pseudowire 55.1.1.3 1 pw-class pwclass1 ! ip route 192.168.1.0 255.255.255.0 Virtual-PPP1
После этого на LNS уже 2 туннеля
LNS#sh vpdn tunnel
L2TP Tunnel Information Total tunnels 2 sessions 2
LocTunID RemTunID Remote Name State Remote Address Sessn L2TP Class/ Count VPDN Group 35949 21672 LAC est 77.1.1.7 1 VPDN-L2TP 49973 18492 LAC_9 est 44.1.1.9 1 VPDN-L2TP
Работа OSPF в L2TPv2 В случае подключение удаленных офисов через L2TPv2 – нет ограничений в использовании динамических протоколов маршрутизации. Для включения OSPF заведем на каждом удаленном маршрутизаторе по сети на loopback-е:
LNS# interface Loopback0 ip address 3.3.3.3 255.255.255.255 router ospf 1 network 3.3.3.3 0.0.0.0 area 0
LAC# interface Loopback0 ip address 7.7.7.7 255.255.255.255 ! interface Loopback1 ip address 77.77.77.77 255.255.255.255 ! router ospf 1 router-id 7.7.7.7 network 7.7.7.7 0.0.0.0 area 0 network 77.77.77.77 0.0.0.0 area 0
LAC_9# interface Loopback0 ip address 9.9.9.9 255.255.255.255 ! interface Loopback1 ip address 99.99.99.99 255.255.255.255 ! router ospf 1 router-id 9.9.9.9 network 9.9.9.9 0.0.0.0 area 0 network 99.99.99.99 0.0.0.0 area 0
Проверяем OSPF соседство и настроенные маршруты
LNS#sh ip ospf neighbor
Все региональные офисы видят маршруты друг друга через R3 – L2TPv2 HUB LAC_9#shiprouteospf (видны маршруты маршрутизатораR7) 7.0.0.0/32 is subnetted, 1 subnets O 7.7.7.7 [110/3] via 3.3.3.3, 00:02:14, Virtual-PPP1 77.0.0.0/32 is subnetted, 1 subnets O 77.77.77.77 [110/3] via 3.3.3.3, 00:02:14, Virtual-PPP1
Трассировка между удаленными офисами: LAC_9#traceroute 77.77.77.77 source 99.99.99.99 Type escape sequence to abort. Tracing the route to 77.77.77.77 VRF info: (vrf in name/id, vrf out name/id) 1 3.3.3.3 5 msec 2 msec 4 msec 2 7.7.7.7 5 msec 4 msec *
В случае не использования OSPF, каждое добавление нового регионального офиса требует статического добавления маршрутов на каждом существующем маршрутизаторе (и региональном и L2TP HUBe) с адресом достижения – ip адрес ppp интерфейса. В случае хорошего дизайна распределения IP адресов мы можем ограничиться тем, что на региональных маршрутизаторах 1 раз добавили суммарный маршрут до всей внутренних региональных сетей, например 192.168.25.0/24 на interface virtual-ppp VPN HUBa, тогда при подключении новой подсети а-ля 192.168.25.16/29 нам не нужно будет ничего добавлять на региональных маршрутизаторах, останется только лишь на VPN HUBе указать за каким vitual-ppp интерфейсом нового регионального маршрутизатора находится эта сеть: HUB(conf)#ip route 192.168.25.16 255.255.255.248 16.16.16.16 ( Спасибо самым стойким и усидчивым читателям, дошедшим до конца данной статьи, за ваше внимание и терпение. Как я уже отмечал в начале статьи, мне бы хотелось, чтобы данный обзор стал небольшим сборником и справочным материалом, который необязательно помнить наизусть, но к которому можно всегда обратиться. Надеюсь, что это реально поможет моим коллегам по «цеху» учесть нюансы в построении качественного, красивого и грамотного сетевого дизайна, избежать подводных камней и в целом сделать свою работу на высшем уровне! С вами был Семенов Вадим.
P.S. Ну и на десерт: для любопытных и пытливых умов, желающих ознакомиться поглубже в способе инкапсуляции того или иного типа VPN-а, поглубже разобраться в формате различных заголовков — возможно скачать дампы пакетов, собранных при обзоре указанных выше VPN-ов здесь.
