По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В сегодняшней статье покажем пример настройки DMVPN – Dynamic Multipoint VPN, что является VPN решением компании Cisco. Данное решение используется, когда требуется высокая масштабируемость и легкость настройки при подключении филиалов к головному офису. DMPVN одно из самых масштабируемых и эффективных решений VPN поддерживаемых компанией Cisco. В основном оно используется при топологии Hub-and-Spoke, где вы хотели бы видеть прямые VPN туннели Spoke-to-Spoke в дополнение к обычным Spoke-to-Hub туннелям. Это означает, что филиалы смогут общаться с друг другом напрямую, без необходимости прохождение трафика через HQ. Как уже упоминали, эта технология является проприетарной технологией Cisco. Если вам необходимо подключить более десяти сайтов к головному офису, то DMPVN будет идеальным выбором. Кроме того, DMPVN поддерживает не только Hub-and-Spoke, но и Full-Mesh топологию, так как все сайты имеют между собой связность без необходимости настройки статических VPN туннелей между сайтами. Некоторые характеристики DMVPN Для начала перечислим важные характеристики данного способа организации Site-to-Site VPN для лучшего понимания: Центральный маршрутизатор (HUB) - данный роутер работает как DMVPN сервер, и Spoke маршрутизаторы работают как DMVPN клиенты; У данного маршрутизатора есть публичный статический IP-адрес на WAN интерфейсе; У Spoke маршрутизаторов на WAN интерфейсах может как статический, так и динамический публичный IP-адрес; У каждого филиала (Spoke) есть IPSEC туннель к головному офису (Hub); Spoke-to-Spoke - туннели устанавливаются при возникновении необходимости, когда есть движение трафика между филиалами. Таким образом, трафик может не ходить через головной офис, а использовать прямые туннели между филиалами; Все туннели используют Multipoint GRE c IPSEC; NHRP (Next Hop Resolution Protocol) - данный протокол используется для установления соответствий между приватными IP туннельных интерфейсов с публичными WAN адресами Описанные выше NHRP соответствия будут храниться на NHRP сервере, чем в нашем случае является HUB роутер. Каждый филиал устанавливает соединение с головным офисом и регистрирует свой публичный IP-адрес и его приватный IP-адрес тунеля; Когда филиалу необходимо отправить пакеты в подсеть другого филиала, он запрашивает NHRP сервер для получения информации о внешнем публичном адресе целевого филиала; Для лучшей масштабируемости советуем использовать один из протоколов динамический маршрутизации между всеми роутерами – например, EIGRP; Еще раз кратко о технологиях, которые использует DMVPN: Multipoint GRE; IPSEC; NHRP – Next Hop Resolution Protocol; Статическая или динамическая маршрутизация; Настройка маршрутизатора Конкретно в нашем примере у нас будет HUB маршрутизатор и два филиала. И, как было описано ранее, HUB – это DMVPN cервер, а филиалы – DMPVN клиенты. В нашем примере в качестве маршрутизатора используется CISCO1921/K9 Сначала настраиваем HUB маршрутизатор – ему необходимо присвоить статический IP – адрес на внешнем WAN-интерфейсе: ! Настраиваем интерфейсы interface GigabitEthernet0/0 description to Internet-WAN ip address 10.10.10.1 255.255.255.252 ! interface GigabitEthernet0/1 description to LAN ip address 192.168.160.1 255.255.255.0 duplex auto ! Настраиваем туннельный интерфейс, который является улучшенным GRE (Multipoint GRE) interface Tunnel1 description DMVPN Tunnel ip address 172.16.1.1 255.255.255.0 // выбираем приватную подсеть для туннелей no ip redirects ip nhrp authentication nhrp1234 // аутентификация между маршрутизаторами ip nhrp network-id 1 // сетевой идентификатор, который должен быть одинаковым на всех маршрутизаторах load-interval 30 keepalive 5 10 tunnel source GigabitEthernet0/0 // назначаем источником туннеля WAN интерфейс tunnel mode gre multipoint // определяем туннель как mGRE tunnel protection ipsec profile protect-gre // шифруем трафик в туннеле с помощью IPSEC ip mtu 1440 // уменьшаем MTU для того, чтобы разрешить оверхед на mGRE и IPSEC ip nhrp map multicast dynamic // разрешаем форвардить мультикаст трафик между туннелями. ! Настраиваем IPSEC на главном роутере crypto isakmp policy 1 encr 3des hash md5 authentication pre-share group 2 crypto isakmp key isakmp1234 address 0.0.0.0 0.0.0.0 // принимать соединения от любого источника при наличии динамических филиалов ! crypto ipsec transform-set TS esp-3des esp-md5-hmac mode tunnel ! ! crypto ipsec profile protect-gre // профиль добавленный к mGRE туннелю для шифрования set security-association lifetime seconds 86400 set transform-set TS ! Настраиваем статическую маршрутизацию на HUB маршрутизаторе ip route 192.168.164.0 255.255.255.0 172.16.1.2 // удаленные подсети доступны через IP удаленного туннеля ip route 192.168.161.0 255.255.255.0 172.16.1.3 // удаленные подсети доступны через IP удаленного туннеля Затем настраиваем маршрутизаторы в филиалах (Spoke роутеры) - у одного маршрутизатора статический айпишник на WAN интерфейсе, и у другого динамический, получаемый по DHCP. Первый маршрутизатор в филиале, с динамическим IP: interface GigabitEthernet0/0 description WAN to Internet ip address dhcp duplex auto speed auto interface GigabitEthernet0/1 description To LAN ip address 192.168.164.1 255.255.255.0 duplex auto speed auto interface Tunnel1 ip address 172.16.1.2 255.255.255.0 // помещаем в ту же подсеть что и другие туннели no ip redirects ip nhrp map multicast dynamic // разрешаем форвардить мультикаст трафик между туннелями tunnel source GigabitEthernet0/0 // “source”- WAN интерфейс tunnel mode gre multipoint tunnel protection ipsec profile protect-gre ip nhrp authentication nhrp1234 ip nhrp map 172.16.1.1 10.10.10.1 // соответствие HUB адреса туннеля с HUB адресом WAN ip nhrp network-id 1 ip nhrp nhs 172.16.1.1 // настройка NHRP ip nhrp registration no-unique // если NHRP процесс завершился (поиск соответствия) для определенного IP, то больше данный процесс не запустится ip nhrp map multicast 10.10.10.1 // Отправка milticast трафика только в Hub. Головной маршрутизатор будет получать весь мультикаст трафик (например, обновления протокола маршрутизации) и отправлять его всем Spoke маршрутизаторам ip mtu 1440 load-interval 30 keepalive 5 10 crypto isakmp policy 1 encr 3des hash md5 authentication pre-share group 2 crypto isakmp key isakmp1234 address 0.0.0.0 0.0.0.0 // Филиалы должны разрешать подклюения с любого адреса для формирования IPSEC VPN туннелей с другими филиалами ! ! crypto ipsec transform-set TS esp-3des esp-md5-hmac mode tunnel ! crypto ipsec profile protect-gre set security-association lifetime seconds 86400 set transform-set TS ip route 192.168.160.0 255.255.255.0 172.16.1.1 // Маршрут для HUB ip route 192.168.161.0 255.255.255.0 172.16.1.3 // Маршрут для другого филиала Spoke site Второй филиальный маршрутизатор, со статическим IP: interface GigabitEthernet0/0 description TO Internet ip address 10.10.10.9 255.255.255.252 duplex auto speed auto interface GigabitEthernet0/1 description To: LAN ip address 192.168.161.1 255.255.255.0 duplex auto speed auto interface Tunnel1 ip address 172.16.1.3 255.255.255.0 // должен быть в той же подсети что и другие туннели no ip redirects ip nhrp map multicast dynamic // разрешаем форвард мульткастов между туннелями. tunnel source GigabitEthernet0/0 tunnel mode gre multipoint tunnel protection ipsec profile protect-gre ip nhrp authentication nhrp1234 ip nhrp map 172.16.1.1 10.10.10.1 // мапируем адрес HUB тунеля к WAN адресу ip nhrp network-id 1 ip nhrp nhs 172.16.1.1 // настраиваем NHRP клиент с указанием адреса сервера ip nhrp registration no-unique ip nhrp map multicast 10.10.10.1 ip mtu 1440 load-interval 30 keepalive 5 10 crypto isakmp policy 1 encr 3des hash md5 authentication pre-share group 2 crypto isakmp key isakmp1234 address 0.0.0.0 0.0.0.0 ! crypto ipsec transform-set TS esp-3des esp-md5-hmac mode tunnel ! !crypto ipsec profile protect-gre set security-association lifetime seconds 86400 set transform-set TS ip route 192.168.160.0 255.255.255.0 172.16.1.1 // маршрут до головного маршрутизатор ip route 192.168.164.0 255.255.255.0 172.16.1.2 // маршрут до другого филиала Переходим к тестированию: show dmvpn // проверяем статус DMVPN и NHRP show crypto isakmp sa // проверяем IPSEC cвязность между маршрутизаторами ping 192.168.164.1 // пингуем для проверки ping 192.168.1.1 В нашем примере использовалась статическая маршрутизация, но при большом количестве филиалов необходимо использовать протоколы динамический маршрутизации для уменьшения ручного труда и риска ошибки.
img
Модель Open Systems Interconnection (OSI) – это скелет, фундамент и база всех сетевых сущностей. Модель определяет сетевые протоколы, распределяя их на 7 логических уровней. Важно отметить, что в любом процессе, управление сетевой передачей переходит от уровня к уровню, последовательно подключая протоколы на каждом из уровней. Видео: модель OSI за 7 минут Нижние уровни отвечают за физические параметры передачи, такие как электрические сигналы. Да – да, сигналы в проводах передаются с помощью представления в токи :) Токи представляются в виде последовательности единиц и нулей (1 и 0), затем, данные декодируются и маршрутизируются по сети. Более высокие уровни охватывают запросы, связанные с представлением данных. Условно говоря, более высокие уровни отвечают за сетевые данные с точки зрения пользователя. Модель OSI была изначально придумана как стандартный подход, архитектура или паттерн, который бы описывал сетевое взаимодействие любого сетевого приложения. Давайте разберемся поподробнее? #01: Физический (physical) уровень На первом уровне модели OSI происходит передача физических сигналов (токов, света, радио) от источника к получателю. На этом уровне мы оперируем кабелями, контактами в разъемах, кодированием единиц и нулей, модуляцией и так далее. Среди технологий, которые живут на первом уровне, можно выделить самый основной стандарт - Ethernet. Он есть сейчас в каждом доме. Отметим, что в качестве носителя данных могут выступать не только электрические токи. Радиочастоты, световые или инфракрасные волны используются также повсеместно в современных сетях. Сетевые устройства, которые относят к первому уровню это концентраторы и репитеры – то есть «глупые» железки, которые могут просто работать с физическим сигналом, не вникая в его логику (не декодируя). #02: Канальный (data Link) уровень Представьте, мы получили физический сигнал с первого уровня – физического. Это набор напряжений разной амплитуды, волн или радиочастот. При получении, на втором уровне проверяются и исправляются ошибки передачи. На втором уровне мы оперируем понятием «фрейм», или как еще говорят «кадр». Тут появляются первые идентификаторы – MAC – адреса. Они состоят из 48 бит и выглядят примерно так: 00:16:52:00:1f:03. Канальный уровень сложный. Поэтому, его условно говоря делят на два подуровня: управление логическим каналом (LLC, Logical Link Control) и управление доступом к среде (MAC, Media Access Control). На этом уровне обитают такие устройства как коммутаторы и мосты. Кстати! Стандарт Ethernet тоже тут. Он уютно расположился на первом и втором (1 и 2) уровнях модели OSI. #03: Сетевой (network) уровень Идем вверх! Сетевой уровень вводит термин «маршрутизация» и, соответственно, IP – адрес. Кстати, для преобразования IP – адресов в MAC – адреса и обратно используется протокол ARP. Именно на этом уровне происходит маршрутизация трафика, как таковая. Если мы хотим попасть на сайт wiki.merionet.ru, то мы отправляем DNS – запрос, получаем ответ в виде IP – адреса и подставляем его в пакет. Да – да, если на втором уровне мы используем термин фрейм/кадр, как мы говорили ранее, то здесь мы используем пакет. Из устройств здесь живет его величество маршрутизатор :) Процесс, когда данные передаются с верхних уровней на нижние называется инкапсуляцией данных, а когда наоборот, наверх, с первого, физического к седьмому, то этот процесс называется декапсуляцией данных #04: Транспортный (transport) уровень Транспортный уровень, как можно понять из названия, обеспечивает передачу данных по сети. Здесь две основных рок – звезды – TCP и UDP. Разница в том, что различный транспорт применяется для разной категории трафика. Принцип такой: Трафик чувствителен к потерям - нет проблем, TCP (Transmission Control Protocol)! Он обеспечивает контроль за передачей данных; Немного потеряем – не страшно - по факту, сейчас, когда вы читаете эту статью, пару пакетов могло и потеряться. Но это не чувствуется для вас, как для пользователя. UDP (User Datagram Protocol) вам подойдет. А если бы это была телефония? Потеря пакетов там критична, так как голос в реальном времени начнет попросту «квакать»; #05: Сеансовый (session) уровень Попросите любого сетевого инженера объяснить вам сеансовый уровень. Ему будет трудно это сделать, инфа 100%. Дело в том, что в повседневной работе, сетевой инженер взаимодействует с первыми четырьмя уровнями – физическим, канальным, сетевым и транспортным. Остальные, или так называемые «верхние» уровни относятся больше к работе разработчиков софта :) Но мы попробуем! Сеансовый уровень занимается тем, что управляет соединениями, или попросту говоря, сессиями. Он их разрывает. Помните мем про «НЕ БЫЛО НИ ЕДИНОГО РАЗРЫВА»? Мы помним. Так вот, это пятый уровень постарался :) #06 Уровень представления (presentation) На шестом уровне творится преобразование форматов сообщений, такое как кодирование или сжатие. Тут живут JPEG и GIF, например. Так же уровень ответственен за передачу потока на четвертый (транспортный уровень). #07 Уровень приложения (application) На седьмом этаже, на самой верхушке айсберга, обитает уровень приложений! Тут находятся сетевые службы, которые позволяют нам, как конечным пользователям, серфить просторы интернета. Гляньте, по какому протоколу у вас открыта наша база знаний? Правильно, HTTPS. Этот парень с седьмого этажа. Еще тут живут простой HTTP, FTP и SMTP.
img
Почитайте первую часть статьи. Первая проблема. Два роутера работают с одной областью OSPF, и каждый роутер имеет loopback интерфейс, объявленный в OSPF. Вот вывод таблиц маршрутизации: Как мы можем наблюдать, что роутер R1 узнал о сети 10.2.2.0/24 от роутера R2, но в таблице маршрутизации роутера R2 пусто. Что не так? Видно, что OSPF не включен на интерфейсе loopback0 роутера R1, так что же мы тогда объявляем в сетях? Похоже, мы объявляем сеть 10.10.1.0/24, но эта сеть не настроена ни на одном интерфейсе... Сеть 10.1.1.0/24 настроена на интерфейсе loopback0 роутера R1. Здесь вы видите неправильно введенную команду network. Удалим ее. R1(config)#router ospf 1 R1(config-router)#no network 10.10.1.1 0.0.0.0 area 0 R1(config-router)#network 10.1.1.0 0.0.0.255 area 0 Давайте удостоверимся, что команда network настроена правильно. Проблема устранена! Эта проблема может показаться не серьезной, но использование неправильных сетевых операторов - это то, что происходит постоянно. Особенно если мы используем меньшие подсети (например, /27 или /28 или аналогичные), люди склонны делать ошибки с обратными маскам. Итог урока: убедитесь, что вы настроили правильный сетевой адрес, обратную маску и область. Видео: протокол OSPF (Open Shortest Path First) за 8 минут Урок №2 Очередная возможная ситуация. Опять два роутера, но другая проблема. Вот таблицы маршрутизации: В очередной раз роутер R2 не увидел сеть 10.1.1.0/24. Что интересно, что роутер R1 не имеет сети 10.1.1.0/24 в своей таблице маршрутизации как непосредственно подключенной. Мы можем проверить, что роутер R1 использует правильную настройку команды network. Поскольку R1 даже не имеет сети в своей таблице маршрутизации, предположим, что проблема с интерфейсом. Кажется, кто-то забыл применить команду "no shutdown" на интерфейсе. R1(config)#interface loopback 0 R1(config-if)#no shutdown Давайте включим интерфейс. И теперь он появляется в таблице маршрутизации роутера R2. Итог урока: нельзя объявлять то, чего у тебя нет! Урок №3 Новый урок! Одна область, опять два роутера... мы хотели бы иметь "full connectivity", но не работает OSPF ... вот вывод таблиц маршрутизации: Роутер R1 не показывает никаких маршрутов OSPF, R2 показывает ... Необходимо выяснить, что не так: Быстро взглянем на роутер R2, чтобы убедиться, что он действительно объявляет правильную сеть(и). Да это так и есть. Вывод роутера R1 более интересен ... видно, что у него настроен distribute-list. В этом заключается наша проблема. Давайте удалим distribute-list. R1(config)#router ospf 1 R1(config-router)#no distribute-list 1 in Эта команда отключит его. Задача решена! Итог урока: знать о distribute-list, запрещающий объявление и / или установку префиксов в таблице маршрутизации. Урок №4 Взглянем на более сложные проблемы OSPF. На изображении выше мы имеем роутер R1 и роутер R2, но на этот раз мы имеем конфигурацию OSPF с несколькими областями. Вот конфигурация OSPF этих роутеров: Видно, что все сети были объявлены. Область 2 не связана напрямую с областью 0, поэтому была создана виртуальная связь. Роутер R1, однако, не увидел сеть 2.2.2.0/24 от роутера R2, но роутер R2 увидел сеть 1.1.1.0/24. Лучше всего начать с виртуальной линии здесь: Хм, это выглядит не очень хорошо. Виртуальная связь отключена. Обратите внимание на IP-адреса, которые мы видим здесь, это IP-адреса, настроенные на интерфейсах FastEthernet обоих маршрутизаторов. Всякий раз, когда мы настраиваем виртуальное соединение, нам нужно настроить идентификатор маршрутизатора OSPF другой стороны, а не IP-адрес другой стороны! Вот ошибка, так что давайте исправим ее. R1(config)#router ospf 1 R1(config-router)#no area 12 virtual-link 192.168.12.2 R1(config-router)#area 12 virtual-link 2.2.2.2 R2(config)#router ospf 1 R2(config-router)#no area 12 virtual-link 192.168.12.1 R2(config-router)#area 12 virtual-link 1.1.1.1 Вот так должна выглядеть virtual-link, настроенная между идентификаторами маршрутизаторов OSPF. Сразу после ввода правильных команд появятся данные сообщения в консоли. Запись OSPF для сети 2.2.2.0/24 появилась. Урок №5 Другая проблема. Те же роутеры, но появился "домен внешней маршрутизации". Это может быть другой протокол маршрутизации, такой как RIP или EIGRP, который мы будем распространять в OSPF. R2 перераспределяет сеть 2.2.2.0 / 24 в OSPF, но по какой-то причине она не отображается на R1. Чтобы было интересно, мы не будем просматривать конфигурацию OSPF на роутерах. Нет сети 2.2.2.0/24 на роутере R1, поэтому давайте изучим роутер R2. Как мы можем видеть, сеть находится в таблице маршрутизации роутера R2 как directly connected. Как мы можем видеть роутер R2 был настроен для перераспределения напрямую подключенных сетей. Это должно включать сеть 2.2.2.0/24 на интерфейса loopback0. Однако в базе данных OSPF пусто? Что может быть причиной этого? Возможно, вы помните правила различных типов областей OSPF. Давайте выясним, что это за область! Вот и объяснение, это stub area! Stub area не допускают LSA type 5 (внешние маршруты). Мы можем либо превратить эту область в normal area или NSSA. Давайте переведем в NSSA. R1(config)#router ospf 1 R1(config-router)#no area 12 stub R1(config-router)#area 12 nssa R2(config)#router ospf 1 R2(config-router)#no area 12 stub R2(config-router)#area 12 nssa Изменим тип области на обоих маршрутизаторах. Область NSSA допускает внешние маршруты с помощью LSA type 7. Наша сеть 2.2.2.0 / 24 теперь в базе данных OSPF маршрутизатора R2. Итог урока: Stub area не допускают внешних префиксов (LSA Type 5). Либо измените область на NSSA, либо прекратите перераспределение. Урок №6 Очередная проблема. Проблема default route OSPF. На рисунке имеются роутер R1 и роутер R2, и сеть 192.168.12.0 /24 объявленная в OSPF. Loopback интерфейсы роутера R2 не объявляется в OSPF, но мы используем default route, чтобы роутер R1 мог добраться до них. Здесь представлены конфигурации OSPF: Видно, что в выводе роутера R2 присутствует команда default-information originate для объявления default route. Увы, но мы не видим default route на роутере R1. Будем искать неполадки в настройке. Давайте проверим роутер R2: В таблице маршрутизации роутера R2 не виден default route. Чтобы OSPF объявлял default route, можно использовать два варианта: Убедитесь, что у вас есть default route в routing table (невозможно объявлять то, чего нет); Примените команду default-information originate always. Она объявит default route, даже если он не прописан. R2(config)#ip route 0.0.0.0 0.0.0.0 null 0 Выше первый метод решения проблемы. Мы создадим default route на роутере R2. Обычно указывается default route на ISP роутере, но сейчас другого роутера нет. Мы укажем default route для интерфейса null0, и он будет внесен в routing table. Правило работает! R2(config)#no ip route 0.0.0.0 0.0.0.0 null 0 R2(config)#router ospf 1 R2(config-router)#default-information originate always Итог урока: что бы объявить default route с помощью OSPF, вам нужно иметь default route в таблице маршрутизации или использовать ключевое слово "always". Урок №7 Немного сложнее проблема... те же два роутера , все в зоне 0. Вот настройки OSPF: Ничего особенного, все сети объявлены, и мы используем одну область. Увы ... таблицы маршрутизации пусты! По крайней мере, никакой отсутствует информация о OSPF ... Настройки network выглядят хорошо, так что это хороший момент вникнуть поглубже в OSPF LSDB. Давайте сначала проверим идентификаторы маршрутизатора OSPF: Здесь мы видим OSPF router ID. Если вы внимательно посмотрите на информацию выше, вы заметите что-то необычное. State full, но роутер R1 не выбрал DR / BDR, а роутер R2 выбрал роутер R1 в качестве BDR. Мы можем использовать команду show ip ospf database router для поиска информации от определенного соседа OSPF. Роутер R1 говорит нам, adv router is not-reachable. Это плохо. Роутер R2 также сообщает нам, что роутер R1 недоступен, и если вы посмотрите внимательно, то увидите, что он видит связь как point-to-point. Мы не видим этого в выводе на роутере R1. Это, вероятно, означает, что роутер R1 и роутер R2 используют другой тип сети OSPF, что приводит к разнице в LSDB. Это не позволит нашим роутерам устанавливать маршруты в таблицу маршрутизации! Теперь мы кое-что выяснили. Тип сети отличается ... широковещательная передача на роутере R2 и точка-точка на роутере R1. Нам действительно удалось установить соседство OSPF с этим, но возникает разница в LSDB. Произведем исправления. R1(config)#interface fa0/0 R1(config-if)#ip ospf network broadcast Изменение типа сети на роутере R1 сделает свое дело. Наконец "О" появляется в наших таблицах маршрутизации...проблема решена! Итог урока: убедитесь, что вы используете правильный тип сети OSPF на обоих роутерах. Урок №8 Очередная внештатная ситуация. OSPF настроено между роутерами R1 и R2, но не все сети объявлены. Loopback интерфейсы роутера R2 перераспределяются в OSPF. Вот настройки обоих роутеров: Мы наблюдаем команду redistribute connected на роутере R2, которая должна перераспределить сети на интерфейсах обратной связи в OSPF. Однако здесь ничего нет ... Обычно было бы неплохо проверить, есть ли distribute list или нет. Ключ к решению этой проблемы - эта команда. Если вы наберете redistribute connected OSPF будет распространять только classful networks. R2(config)#router ospf 1 R2(config-router)#redistribute connected subnets Нам нужно добавить параметр "subnets", позволяющий заставить его выполнять redistribute subnet основных сетей. Ну вот, наша маршрутная таблица заполнена. Итог урока: добавьте параметр " subnets " при использовании перераспределения или перераспределяются только classful networks.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59