Cisco 300-410: VPN, туннелирование и удаленное подключение — Руководство по подготовке

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

Часть Cisco CCNP Enterprise 300-410 ENARSI — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Cisco, или пройдите тесты на время на ExamRoll.io.

Обзор

Технологии VPN, туннелирования и удаленного подключения позволяют организовать частную, управляемую политиками связь через общие сети. Архитектура зависит от выбора инкапсуляции (GRE, IPsec, VTI), протокола обмена ключами (IKEv1/2), разрешения адресов на уровне управления (NHRP в DMVPN) и реалий транспортной сети (MTU, NAT, отказоустойчивость). В этом разделе объясняется, как комбинировать эти строительные блоки для создания масштабируемых, безопасных и отказоустойчивых наложенных сетей (overlay) как для сценариев site-to-site, так и для удаленного доступа.

Основы GRE и IPsec

Generic Routing Encapsulation (GRE) — это простая инкапсуляция без сохранения состояния, которая переносит практически любой протокол уровня 3 через транспортную IP-сеть (underlay). Ключевые свойства:

• Поведение и инкапсуляция: GRE добавляет внешний IP-заголовок размером 20 байт и заголовок GRE размером 4 байта (всего 24 байта). GRE не имеет встроенных средств шифрования или аутентификации.
• Маршрутизация: GRE предоставляет нумерованный туннельный интерфейс, который участвует в маршрутизации и поддерживает отношения соседства IGP в наложенной сети (overlay).
• MTU, фрагментация, MSS: Дополнительные заголовки уменьшают эффективный MTU для полезной нагрузки. Без специальных мер «черные дыры» PMTUD и IP-фрагментация могут снизить производительность. Рекомендуется устанавливать меньшее значение MTU на туннельном интерфейсе и ограничивать TCP MSS, чтобы избежать фрагментации в наложенной сети.

Пример GRE-туннеля точка-точка с безопасными значениями MTU и MSS:

interface Tunnel1
 ip address 172.20.1.2 255.255.255.0
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel source 10.10.2.2
 tunnel destination 10.10.1.1

IPsec обеспечивает конфиденциальность, целостность и защиту от повторов:

• Режимы: Транспортный режим защищает только полезную нагрузку; исходный IP-заголовок сохраняется. Туннельный режим инкапсулирует весь IP-пакет в новый внешний IP-заголовок. GRE over IPsec обычно использует транспортный режим IPsec для минимизации издержек; VTI на основе маршрутизации используют туннельный режим IPsec.
• Селекторы (proxy ID / селекторы трафика): Определяют, какие потоки (описываемые 5-ю элементами, 5-tuple) подлежат защите. VPN на основе политик (policy-based) используют ACL для определения селекторов; VPN на основе маршрутизации (route-based) используют селекторы 0.0.0.0/0 (или ::/0), привязанные к туннельному интерфейсу, где трафик определяется маршрутизацией.
• Шифрование и целостность: AES-GCM обеспечивает аутентифицированное шифрование в одном преобразовании и снижает издержки на пакет по сравнению с AES-CBC + HMAC. Используйте современные группы DH (14/19+) и PFS для обеспечения прямой секретности (forward secrecy). Согласуйте возможности наборов преобразований/предложений (transform/proposal) на обоих узлах.

Компромиссы между фрагментацией и пропускной способностью:

• Предварительная фрагментация (look-ahead fragmentation) работает только в туннельном режиме. Она может повысить пропускную способность, избегая повторной сборки на расшифровывающем хосте, ценой появления дополнительных IP-фрагментов в транспортной сети.
• Фрагментация после шифрования часто используется с GRE over IPsec в транспортном режиме и NAT-T; в сочетании с ограничением MSS это снижает вероятность возникновения «черных дыр» PMTUD.
• PMTUD или фиксированный MTU: Если ICMP в транспортной сети фильтруется, полагайтесь на консервативные значения MTU туннеля и ограничение MSS.

Применение IPsec к GRE с защитой туннеля:

crypto isakmp policy 10
 encr aes 256
 hash sha256
 authentication pre-share
 group 14
 lifetime 28800
crypto isakmp key Test address 0.0.0.0 0.0.0.0
crypto ipsec transform-set TS esp-gcm 256 mode transport
!
crypto ipsec profile GRE-PROF
 set transform-set TS
!
interface Tunnel10
 ip address 10.10.10.1 255.255.255.0
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel mode gre multipoint
 tunnel protection ipsec profile GRE-PROF

Обмен ключами, прохождение NAT и типы VPN

IKE согласовывает SA для IPsec.

• IKEv1: Основной (Main) и Агрессивный (Aggressive) режимы для Фазы 1; Быстрый режим (Quick Mode) для Фазы 2. Настройте политики («crypto isakmp policy»), аутентификацию (PSK или сертификаты), время жизни и группы DH. Для диагностики используйте show crypto isakmp sa и отладку обменов MM/AM/QM и несоответствий proxy ID.
• IKEv2: Модель с единым обменом сообщениями, использующая предложения, политики и профили. Поддерживает несколько дочерних SA, EAP для удаленного доступа и улучшенную сигнализацию об ошибках. FlexVPN стандартизирует использование IKEv2 и поведение на основе маршрутизации через VTI. Для диагностики используйте show crypto ikev2 sa/session, show crypto ipsec sa и отладку.

Прохождение NAT и keepalive-сообщения:

• NAT-T обнаруживает NAT на пути и инкапсулирует ESP в UDP/4500. Убедитесь, что NAT-T включен на обоих узлах. IKE keepalives и Dead Peer Detection (DPD) удаляют устаревшие SA; настройте таймеры в соответствии с требованиями приложений.
• Достижимость источника и назначения туннеля является основополагающей: транспортная сеть (underlay) должна обеспечивать маршрутизацию до конечных точек туннеля. Используйте статические маршруты или динамическую маршрутизацию в транспортной сети, чтобы внешние IP-адреса оставались доступными при отработке отказа.
• GRE keepalives работают для GRE-туннелей точка-точка, но не для mGRE. Для наложенных сетей используйте таймеры IGP, NHRP или BFD. Управляющие пакеты BFD используют порт UDP 3784 и могут быстро обнаруживать сбои на пути; интегрируйте BFD с IGP для достижения сходимости менее чем за секунду.

VPN на основе политик (policy-based) и на основе маршрутизации (route-based):

• На основе политик: Crypto map с селекторами «интересующего трафика» (interesting traffic) на основе ACL. Плюсы: простота для небольших статических сетей site-to-site. Минусы: сложность при большом количестве префиксов, проблемы с асимметричной маршрутизацией и плохая поддержка соединений spoke-to-spoke.
• На основе маршрутизации: Виртуальные туннельные интерфейсы (VTI/dVTI/FlexVPN) с селекторами по умолчанию (any/any); защищаемые потоки определяются маршрутизацией. Плюсы: масштабируемость, поддержка динамической маршрутизации и hairpin/spoke-to-spoke, более простая настройка криптографии. Предпочтительный вариант для современных архитектур.

Удаленный доступ с помощью IKEv2/FlexVPN:

• Используйте профили IKEv2, аутентификацию EAP и dVTI для назначения политик для отдельных пользователей/групп. Для диагностики используйте show crypto ikev2 sa и логи AAA. Ограничение MSS и раздельное туннелирование (split tunneling) смягчают проблемы с MTU и производительностью в разнородных клиентских сетях.

Маршрутизация на основе политик (PBR) для резервирования:

• При направлении потоков, для которых нет маршрута, в туннель или на определенный выходной интерфейс, используйте PBR с командой set ip default next-hop, чтобы указать next-hop по умолчанию, когда в RIB отсутствует подходящий маршрут. Это минимизирует зависимость от статических маршрутов по умолчанию при отработке отказа.

Проектирование и работа DMVPN

DMVPN объединяет mGRE, NHRP и IPsec для создания масштабируемых топологий «звезда» (hub-and-spoke) или «каждый с каждым» (spoke-to-spoke).

• mGRE: Один туннельный интерфейс динамически терминирует множество пиров; на хабе не требуется отдельный туннель для каждого spoke-узла. Конечная точка туннеля — это единый NBMA-адрес типа «любой с любым» (any-to-any).
• NHRP: Преобразует адреса следующих переходов (next hops) оверлейной сети в адреса андерлейной NBMA-сети. Spoke-узел регистрируется на сервере NHRP Next Hop Server (NHS), расположенном на хабе. Запросы NHRP обеспечивают разрешение адресов между spoke-узлами по требованию.
• Spoke-узлы и динамические IP-адреса: Для spoke-узлов за NAT или с динамическими адресами может потребоваться команда ip nhrp registration no-unique, чтобы разрешить регистрацию без глобально уникального NBMA-адреса.
• Фазы:
  • Фаза 1: Spoke-узлы используют хаб для всего трафика; прямое взаимодействие между spoke-узлами отсутствует.
  • Фаза 2: Spoke-узлы формируют прямые туннели после разрешения адресов через NHRP; маршрутизация должна анонсировать префиксы spoke-узлов без суммирования, которое скрывает адреса следующих переходов.
  • Фаза 3: Добавляются NHRP redirect/shortcut для динамического переписывания адресов следующих переходов; это позволяет использовать суммирование на хабе и обеспечивает оптимальную пересылку трафика между spoke-узлами.
• OSPF поверх DMVPN: По умолчанию для mGRE используется тип сети OSPF broadcast; хаб должен стать DR для стабилизации отношений соседства — установите приоритет OSPF > 1 на хабе и 0 на spoke-узлах. В качестве альтернативы можно использовать тип сети point-to-multipoint, чтобы избежать выборов DR/BDR, но это приведет к большему объему LSA.
• IPv6: Построение соседства IPv6 поверх DMVPN выполняется с помощью команды tunnel mode gre multipoint ipv6 и использования NHRP для сопоставлений IPv6. Оверлейные сети с двойным стеком (dual-stack) могут одновременно поддерживать IPv4 и IPv6 на одном и том же интерфейсе mGRE.
• Интеграция с IPsec: Защитите mGRE с помощью единого профиля IPsec, используя tunnel protection. Для GRE поверх IPsec предпочтительно использовать транспортный режим (transport mode).
• MTU и фрагментация: Применяйте консервативные значения ip mtu и ip tcp adjust-mss, а также рассмотрите возможность использования crypto ipsec fragmentation after-encryption, чтобы максимизировать согласованный TCP MSS и избежать сбоев PMTUD.

Типичные выдержки конфигурации для Фазы 3:

! Hub
interface Tunnel10
 ip address 10.0.0.1 255.255.255.0
 ip nhrp map multicast dynamic
 ip nhrp network-id 10
 ip nhrp redirect
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN-PROF
 ip ospf network broadcast
 ip ospf priority 100

! Spoke
interface Tunnel10
 ip address 10.0.0.11 255.255.255.0
 ip nhrp network-id 10
 ip nhrp nhs 10.0.0.1
 ip nhrp map multicast dynamic
 ip nhrp shortcut
 ip nhrp registration no-unique
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN-PROF

Прохождение NAT: Убедитесь, что NAT-T включен и что хаб доступен по портам UDP/500 и UDP/4500. Для динамических туннелей между spoke-узлами требуется, чтобы андерлейная сеть разрешала прямой трафик UDP/4500 и ESP/UDP между ними, если в пути нет ретрансляторов NAT-T.

Эксплуатация и устранение неполадок:

• Используйте команды show dmvpn, show ip nhrp и show crypto ipsec sa для проверки регистраций NHRP и ассоциаций безопасности IPsec (SA).
• Для маршрутизации убедитесь, что в Фазе 2 анонсы от хаба не скрывают специфику spoke-узлов, а в Фазе 3 происходят NHRP redirect/shortcut.
• mGRE не поддерживает GRE keepalives; для обнаружения сбоев используйте таймеры NHRP/IGP или BFD.

IPv6, безопасность Dual-Stack и отказоустойчивое удалённое подключение

Туннели IPv6 поверх IPv4:

• GRE поверх базовой сети IPv4 (underlay) прозрачно переносит полезную нагрузку IPv6; защищается с помощью IPsec, как описано выше.
• 6in4 (tunnel mode ipv6ip) — это простой вариант точка-точка, но ему не хватает масштабируемости DMVPN/mGRE.
• Оверлейные сети dual-stack запускают IPv4 и IPv6 на одном и том же GRE/mGRE, защищённые одним набором ассоциаций IPsec (SA) или отдельными SA, если того требуют политики.

Заметки по безопасности IPv6:

• RA Guard фильтрует нелегитимные объявления маршрутизатора IPv6 (Router Advertisements) на сегментах L2, но не может проверять трафик внутри туннелей; он не обеспечивает защиту, когда трафик IPv6 туннелируется. Обеспечивайте безопасность на конечных точках туннеля и на уровне маршрутизации оверлейной сети.

Диагностика удалённого доступа и отказоустойчивый дизайн:

• Инструментарий:

crypto isakmp policy 10
 encr aes 256
 hash sha256
 authentication pre-share
 group 14
 lifetime 28800
crypto isakmp key Test address 0.0.0.0 0.0.0.0
crypto ipsec transform-set TS esp-gcm 256 mode transport
!
crypto ipsec profile GRE-PROF
 set transform-set TS
!
interface Tunnel10
 ip address 10.10.10.1 255.255.255.0
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel mode gre multipoint
 tunnel protection ipsec profile GRE-PROF

,

! Hub
interface Tunnel10
 ip address 10.0.0.1 255.255.255.0
 ip nhrp map multicast dynamic
 ip nhrp network-id 10
 ip nhrp redirect
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN-PROF
 ip ospf network broadcast
 ip ospf priority 100

! Spoke
interface Tunnel10
 ip address 10.0.0.11 255.255.255.0
 ip nhrp network-id 10
 ip nhrp nhs 10.0.0.1
 ip nhrp map multicast dynamic
 ip nhrp shortcut
 ip nhrp registration no-unique
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN-PROF

,

undefined

и журналы учёта по каждому клиенту. Выполняйте захват трафика на портах UDP/500/4500 и по протоколу ESP/UDP для наблюдения за поведением NAT-T. Убедитесь, что маршруты для split-tunnel установлены на клиенте.

• Оптимизация MTU: Клиенты проходят через произвольные сети доступа; включите ограничение TCP MSS (clamping) на головных устройствах (headends) и рассмотрите MSS в диапазоне 1200–1360 для стабильной производительности. Потеря пакетов в сочетании с образованием «чёрных дыр» из-за PMTUD (PMTUD blackholing) — частая причина плохого пользовательского опыта (UX).
• Высокая доступность: Используйте несколько источников туннеля (multi-WAN) с отслеживанием объектов (object tracking) и проверками SLA (SLA probes) для переключения при сбое основного шлюза базовой сети (underlay). Для оверлейных сетей с IGP рассмотрите использование BFD для сокращения таймеров обнаружения сбоев в туннеле. Поддерживайте короткие таймеры пересоздания ключей IKE/дочерних SA, согласованные с кластеризацией головных устройств, чтобы минимизировать потерю криптографического состояния при отказе.
• Политика доступа и селекторы: Предпочитайте удалённый доступ на основе маршрутизации (dVTI), чтобы весь трафик клиента (или только определённые префиксы) маршрутизировался в виртуальный интерфейс; это позволяет избежать хрупких несоответствий селекторов на основе политик.
• Доступность конечных точек: Всегда проверяйте маршрутизацию в базовой сети (underlay) к публичным адресам головного устройства из клиентских сетей. Если требуется управлять трафиком внутри WAN, маршрутизация на основе политик (PBR) с помощью

undefined

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

Практический сценарий

Компания Contoso Retail управляет 150 филиалами, подключёнными через широкополосный доступ. Им требуется безопасное подключение по топологии hub-and-spoke с динамическими связями spoke-to-spoke для репликации данных с кассовых терминалов (Point-of-Sale), поддержка dual-stack и устойчивость к проблемам с MTU/NAT.

Подход:

1. Построить оверлейную сеть DMVPN Phase 3 с mGRE на центральном узле (hub) и филиалах (spokes), защищённую IPsec в транспортном режиме.

• Обоснование: mGRE масштабируется на множество филиалов без необходимости настройки отдельного туннеля на центральном узле для каждого из них. Phase 3 позволяет устанавливать соединения spoke-to-spoke по требованию через NHRP shortcut/redirect, оптимизируя потоки репликации и экономя пропускную способность центрального узла. Транспортный режим минимизирует накладные расходы для GRE поверх IPsec.

2. Стандартизировать использование IKEv2 с современной криптографией и NAT-T.

• Обоснование: IKEv2 упрощает согласование параметров, поддерживает несколько дочерних SA и более чисто обрабатывает ошибки, что идеально подходит для крупных развёртываний. NAT-T (UDP/4500) обеспечивает работу через NAT в филиалах. Используйте AES-GCM с группой DH 19 или 20 и PFS для обеспечения производительности и безопасности.

3. Спроектировать сквозную настройку MTU и включить фрагментацию после шифрования.

• Обоснование: Провайдеры широкополосного доступа часто блокируют ICMP, что нарушает работу PMTUD. Установка

undefined

и

undefined

на туннельных интерфейсах, а также

undefined

, предотвращает образование «чёрных дыр» и максимизирует эффективный размер TCP MSS.

4. Включить функции NHRP для динамического разрешения адресов и работы с филиалами за NAT.

• Обоснование: Команда

undefined

на центральном узле и

undefined

на филиалах создают ярлыки (shortcuts) для Phase 3. Команда

undefined

позволяет филиалам с динамическими/транслируемыми NBMA-адресами успешно регистрироваться.

5. Запустить OSPF поверх оверлейной сети, назначив центральный узел DR, и использовать BFD для быстрого обнаружения сбоев.

• Обоснование: По умолчанию mGRE работает в режиме broadcast; установка приоритета OSPF на центральном узле > 1, а на филиалах — 0, обеспечивает стабильные выборы DR/BDR и уменьшает количество отношений соседства. BFD (UDP/3784) с агрессивными таймерами обеспечивает сходимость менее чем за секунду при сбоях туннеля.

6. Добавить поддержку IPv6 на тот же интерфейс DMVPN наряду с IPv4.

• Обоснование: Команда

undefined

включает установление соседства IPv6 через mGRE. Маршрутизация dual-stack позволяет избежать создания параллельных инфраструктур. RA Guard неэффективен внутри туннеля, поэтому безопасность IPv6 следует обеспечивать с помощью ACL и политик маршрутизации в оверлейной сети.

7. Усилить безопасность обмена ключами и эксплуатации.

• Обоснование: На начальном этапе используйте предварительно согласованные ключи (preshared keys) (

undefined

для обратной совместимости с устаревшим IKEv1, или связки ключей/профили IKEv2) и затем переходите на сертификаты. Установите соответствующие времена жизни ключей и DPD для удаления устаревших SA. Используйте для мониторинга команды

undefined

,

undefined

,

undefined

,

undefined

и syslog.

8. Обеспечить доступность в базовой сети (underlay) и управлять переключением при сбое с помощью маршрутизации/PBR, где это необходимо.

• Обоснование: Статические маршруты или динамическая маршрутизация в базовой сети должны поддерживать доступность источников туннеля при изменениях в WAN. Если требуется временное управление трафиком, PBR с командой

undefined

может направить трафик на предпочтительный исходящий интерфейс в случае сбоя поиска в RIB.

Такой дизайн обеспечивает масштабируемое, зашифрованное dual-stack подключение с оптимальными путями между филиалами (spoke-to-spoke), предсказуемым поведением MTU, надёжным прохождением NAT и быстрым восстановлением после сбоев.

← Качество обслуживания и защита плоскости управления · Все домены · Сетевые сервисы →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →