Cisco с нуля 18. IPsec VPN между офисами: IKEv2 и VTI

Филиал и главный офис связаны через интернет, а трафик между ними не должен читаться по дороге. В этой статье мы построим защищённый туннель между R1 (главный офис) и RB (маршрутизатор филиала) по технологии IPsec с обменом ключами IKEv2 и туннельным интерфейсом VTI. В результате офисная сеть 192.168.10.0/24 и сеть филиала 192.168.60.0/24 смогут общаться друг с другом, а всё, что они пересылают через интернет, будет зашифровано. Гостевую сеть (VLAN 20) в туннель мы намеренно не пускаем, а сеть управления (VLAN 99) добавляется только при необходимости: подробности в разделе про маршрутизацию.

Что понадобится

Статья самостоятельная: достаточно, чтобы выполнялись условия ниже. Если какой-то пункт неясен, откройте соответствующую статью серии.

• R1 с адресом 203.0.113.2/30 на GigabitEthernet0/0/0 и маршрутом по умолчанию на 203.0.113.1 (статическая маршрутизация). LAN-подинтерфейсы R1 в VLAN 10, 20 и 99 уже настроены (маршрутизация между VLAN).
• RB с адресом 192.0.2.66/30 на внешнем порту, маршрутом по умолчанию на 192.0.2.65 и LAN-сетью 192.168.60.0/24 (адрес RB в ней — 192.168.60.1). В примерах для RB используются те же имена портов, что и у R1; проверьте свои командой show ip interface brief.
• Рабочий «интернет» между 203.0.113.1 и 192.0.2.65: с R1 проходит ping 192.0.2.66, а с RB — ping 203.0.113.2. Без этого туннель не поднимется ни при какой настройке. Если на внешнем интерфейсе R1 уже применён список OUTSIDE-IN из статьи про ACL, ping с RB до R1 может блокироваться им (там разрешены только ответы на ping): проверяйте ping от R1 к RB и при необходимости временно разрешите icmp echo для адреса RB.
• Консольный доступ хотя бы к одному из маршрутизаторов или reload in как страховка (см. ниже). Если вы настраиваете RB по SSH через тот же канал, ошибка может отрезать вас от него.
• Перед началом сохраните рабочую конфигурацию на обоих маршрутизаторах: copy running-config startup-config и копия copy running-config flash:pre-ipsec.cfg. Таймер reload in возвращает устройство именно к сохранённой конфигурации: если вы не сохранили результат предыдущих статей, он будет потерян.
• Работа лабораторная: повторить её можно на двух реальных маршрутизаторах в тестовой сети или в эмуляторе (GNS3, EVE-NG, Cisco Modeling Labs; в Packet Tracer поведение отдельных команд может отличаться). Не пробуйте на боевом устройстве, через которое работают пользователи.
• Маршрутизатор, который умеет IPsec с достаточно стойкой криптографией. На ISR 4000 полный крипто-функционал требует лицензию HSEC (лицензия на «полную» криптографию): по данным Cisco, без неё доступно до 1000 защищённых туннелей и 250 Мбит/с шифрованного трафика, для небольшого офиса этого обычно хватает. На классической IOS 15.x (например, ISR G2) IKEv2 доступен с версии 15.1(1)T.
• Коммутаторы Catalyst 9000 для этой задачи обычно не подходят: IPsec есть лишь на отдельных моделях линейки X. По документации Cisco, на 9300X он появился в IOS XE 17.6.2 и требует ключ HSECK9; на 9400X с Supervisor 2 — с 17.10.1. На 9300X поддерживаются только два набора transform set (esp-aes esp-sha-hmac и esp-gcm), поэтому пример из статьи с esp-aes 256 esp-sha256-hmac придётся заменить вариантом с AES-GCM из подсказки ниже. Кроме того, VTI не работает, если на транспортном интерфейсе включён NAT. Остальные условия (лицензии, версии) проверьте в руководстве для вашей модели.

IPsec простыми словами

IPsec — набор протоколов, который шифрует и защищает от подмены IP-трафик между двумя узлами. Для нас важны две части.

• IKE (Internet Key Exchange) — «переговоры». Маршрутизаторы проверяют друг друга (аутентифицируются) и договариваются, какие алгоритмы использовать и какими ключами пользоваться. Результат переговоров называется IKE SA (Security Association, «ассоциация безопасности»).
• ESP (Encapsulating Security Payload, IP-протокол номер 50) — «перевозка». Он шифрует и подписывает сами пользовательские пакеты. Параметры для ESP хранятся в IPsec SA; в терминах IKEv2 её также называют Child SA.

Каждая SA живёт ограниченное время (по умолчанию IPsec SA на Cisco действует 3600 секунд или 4 608 000 КБ), потом ключи автоматически заменяются. Вручную это делать не нужно.

IKEv1 и IKEv2

Есть две версии протокола переговоров. В IKEv1 обмен делится на две фазы: фаза 1 — шесть пакетов в основном режиме, фаза 2 — ещё три. IKEv2 проще и устойчивее: параметры согласуются меньшим числом сообщений, а дочерняя IPsec SA создаётся прямо в ходе аутентификации. В IKEv2 механизмы обнаружения «мёртвого» соседа (DPD) и прохождения NAT (NAT-T) встроены в сам протокол. DPD на Cisco по умолчанию выключен (см. подсказку ниже). В этой статье мы используем только IKEv2; IKEv1 для новых настроек не рекомендуется.

Два способа построить туннель

VTI удобнее по нескольким причинам. Состояние туннеля видно как обычный up/down, на Tunnel можно применять QoS, NAT и ACL, а маршрутизация поверх него работает так же, как на любом другом интерфейсе: статические маршруты и динамические протоколы. Эта статья описывает статический VTI (static VTI, сокращённо sVTI) для связи «офис — офис». Если вы работаете со старой конфигурацией на crypto map, она разобрана в статье Настройка IPsec на Cisco; обратите внимание, что она рассчитана на классическую IOS 15.x и ранние версии IOS XE.

Схема и параметры

Схема стенда:

 VLAN 10/20/99                                        LAN филиала
 192.168.10.0/24                                      192.168.60.0/24

 [SW1]--[R1]================ Интернет ================[RB]--[ПК филиала]
          Gi0/0/0 203.0.113.2          192.0.2.66 Gi0/0/0
          Tunnel1 10.0.101.1  <------>  10.0.101.2 Tunnel1

Туннель связывает только R1 и RB и несёт трафик между этими сетями. Внешние серверы из 192.0.2.0/24 (syslog, NTP, RADIUS и другие) через него недоступны, пока вы сами не добавите к ним маршруты.

Параметры безопасности выбираем на обеих сторонах одинаковыми (они должны совпасть):

Группа DH (Диффи — Хеллмана) — это математическая основа для выработки общего ключа. Cisco для IKEv2 допускает, в частности, группы 14, 15, 16, 19 и 20 (устаревшие 1, 2 и 5 в новых версиях не поддерживаются; Cisco рекомендует группы 14 и выше); точный список зависит от версии. Выбирайте 14, 15, 16, 19 или 20. В примерах используется группа 14: она самая совместимая. Если оба устройства поддерживают группу 19 (эллиптическая кривая, быстрее), можно заменить group 14 на group 19 в crypto ikev2 proposal на обеих сторонах (поддержку проверьте подсказкой ?; на старой IOS 15.x она может отсутствовать). Тогда в выводе show crypto ikev2 sa будет DH Grp:19. Главное, чтобы значения на двух концах совпадали.

В примерах ниже вместо общего ключа (PSK) стоит заглушка <КЛЮЧ_IKEV2>: замените её (вместе с угловыми скобками) на свой длинный случайный ключ из латинских букв, цифр и знаков; на R1 и RB он должен быть одинаковым. О хранении ключа, сертификатах и встроенных настройках IKEv2 (smart defaults) рассказано в справочном разделе после раздела «Откат».

Порты и ACL на внешнем интерфейсе

Для работы туннеля через интернет по пути должны проходить:

• UDP 500 — переговоры IKE;
• UDP 4500 — IKE и ESP внутри UDP, если один из маршрутизаторов находится за NAT (NAT-Traversal, определяется автоматически: обнаружив NAT, IPsec переключается на порт 4500);
• ESP, IP-протокол 50 — сам зашифрованный трафик, если NAT нет.

Строки для R1 (вставьте перед запрещающими правилами; номера последовательностей 4, 5 и 6 поместят их в начало). Имя списка OUTSIDE-IN — то же, что в статье про списки доступа; если у вас другое имя, подставьте своё. Номера 1-9 в этом списке могут занимать строки из других статей серии (например, permit gre в статье про GRE или строки BGP): перед вводом проверьте show ip access-lists OUTSIDE-IN и выберите свободные номера, потому что повторный номер даёт Duplicate sequence number и строка не добавляется.

enable
configure terminal
ip access-list extended OUTSIDE-IN
 4 permit udp host 192.0.2.66 host 203.0.113.2 eq 500
 5 permit udp host 192.0.2.66 host 203.0.113.2 eq 4500
 6 permit esp host 192.0.2.66 host 203.0.113.2
end

На RB в зеркальном виде: источник 203.0.113.2, назначение 192.0.2.66. Порты записаны числами, чтобы не зависеть от имён вроде isakmp. Проверить попадания можно командой show access-lists OUTSIDE-IN: счётчики совпадений у этих строк должны расти при попытках согласования.

Настройка R1

Перед началом:

enable
reload in 30

Настройку делаем сверху вниз: сначала параметры IKEv2, затем IPsec, затем сам интерфейс Tunnel1. Пока tunnel protection не включён, ничего не шифруется и туннель не пытается подняться.

enable
configure terminal
crypto ikev2 proposal PROP-AES256
 encryption aes-cbc-256
 integrity sha256
 group 14
exit
crypto ikev2 policy POL-LAB
 proposal PROP-AES256
exit
crypto ikev2 keyring KR-RB
 peer RB
  address 192.0.2.66
  pre-shared-key <КЛЮЧ_IKEV2>
 exit
exit
crypto ikev2 profile PROF-RB
 match identity remote address 192.0.2.66 255.255.255.255
 authentication local pre-share
 authentication remote pre-share
 keyring local KR-RB
exit
crypto ipsec transform-set TS-AES256-SHA256 esp-aes 256 esp-sha256-hmac
 mode tunnel
exit
crypto ipsec profile IPSEC-PROF
 set transform-set TS-AES256-SHA256
 set ikev2-profile PROF-RB
exit
interface Tunnel1
 description IPsec VTI to RB
 ip address 10.0.101.1 255.255.255.252
 tunnel source GigabitEthernet0/0/0
 tunnel mode ipsec ipv4
 tunnel destination 192.0.2.66
 tunnel protection ipsec profile IPSEC-PROF
end

Что делает каждая часть:

• crypto ikev2 proposal — набор алгоритмов для IKE. Он считается полным, когда заданы шифрование, целостность и группа DH (при AES-GCM строка integrity не нужна и не допускается). Можно перечислить несколько значений в одной строке: приоритет идёт слева направо.
• crypto ikev2 policy — привязывает proposal к «разговору». Policy без условий match подходит ко всем пирам, это нас устраивает.
• crypto ikev2 keyring — связка ключей (keyring), хранилище ключей. Для каждого пира указывается его адрес и общий ключ. Здесь мы используем симметричный вариант pre-shared-key <КЛЮЧ_IKEV2>; в документации есть и пара pre-shared-key local / pre-shared-key remote с разными ключами для каждой стороны.
• crypto ikev2 profile — главный «паспорт» соединения: кого мы принимаем (match identity remote address), как проверяем себя и партнёра (authentication local/remote pre-share) и где лежат ключи (keyring local). Профиль без match identity (или match certificate) считается неполным и не используется. По умолчанию при аутентификации по PSK наш идентификатор (local identity) — это IP-адрес.
• crypto ipsec transform-set — алгоритмы ESP. Для VTI обязателен mode tunnel.
• crypto ipsec profile — связывает transform set и профиль IKEv2. Это аналог crypto map для VTI.
• interface Tunnel1 — сам туннель. tunnel source — наш внешний интерфейс (можно указать и IP-адрес), tunnel destination — адрес RB, tunnel mode ipsec ipv4 — режим «IPsec поверх IPv4» без GRE, tunnel protection ipsec profile — включение шифрования. Слово shared (режим для нескольких туннелей с одним источником и профилем) нам не нужно.

На классической IOS 15.x всё то же самое, но поддержка AES-GCM в IKEv2 там зависит от версии образа и платформы (в части образов, например 15.2S, её нет), поэтому мы взяли aes-cbc-256 с sha256: этот вариант работает везде. Набор алгоритмов esp-sha256-hmac тоже зависит от версии образа и крипто-модуля. Если команда не принимается, проверьте её подсказкой ? (например, ? в режиме crypto ikev2 proposal после слова encryption).

Пример для R1:

enable
configure terminal
crypto ikev2 profile PROF-RB
 dpd 10 2 on-demand
end

Как проверить

Пока RB не настроен, IKEv2 SA не появится, а Tunnel1 может не дойти до состояния up/up: полноценная проверка возможна после настройки RB. Но синтаксис и наличие профилей можно проверить сразу:

enable
show crypto ikev2 profile
show crypto ipsec profile IPSEC-PROF
show running-config interface Tunnel1

Должны отобразиться ваши профили и интерфейс с tunnel protection ipsec profile IPSEC-PROF.

Настройка RB

Зеркальная настройка: адреса пира меняются местами, имена keyring и профиля выбираем свои. Параметры безопасности, ключ и режимы должны быть теми же. Если внешние интерфейсы и маршрут по умолчанию на RB ещё не заданы, они включены в блок ниже; если уже есть, строки безвредно повторят то, что есть (имена портов замените своими).

enable
configure terminal
interface GigabitEthernet0/0/0
 description WAN
 ip address 192.0.2.66 255.255.255.252
 no shutdown
exit
interface GigabitEthernet0/0/1
 description LAN branch
 ip address 192.168.60.1 255.255.255.0
 no shutdown
exit
ip route 0.0.0.0 0.0.0.0 192.0.2.65
crypto ikev2 proposal PROP-AES256
 encryption aes-cbc-256
 integrity sha256
 group 14
exit
crypto ikev2 policy POL-LAB
 proposal PROP-AES256
exit
crypto ikev2 keyring KR-R1
 peer R1
  address 203.0.113.2
  pre-shared-key <КЛЮЧ_IKEV2>
 exit
exit
crypto ikev2 profile PROF-R1
 match identity remote address 203.0.113.2 255.255.255.255
 authentication local pre-share
 authentication remote pre-share
 keyring local KR-R1
exit
crypto ipsec transform-set TS-AES256-SHA256 esp-aes 256 esp-sha256-hmac
 mode tunnel
exit
crypto ipsec profile IPSEC-PROF
 set transform-set TS-AES256-SHA256
 set ikev2-profile PROF-R1
exit
interface Tunnel1
 description IPsec VTI to R1
 ip address 10.0.101.2 255.255.255.252
 tunnel source GigabitEthernet0/0/0
 tunnel mode ipsec ipv4
 tunnel destination 203.0.113.2
 tunnel protection ipsec profile IPSEC-PROF
end

Если вы настраиваете RB удалённо, включите там такую же страховку (reload in 30, отдельной командой) и вносите блок на RB и R1 почти одновременно.

Как проверить

Через несколько секунд после включения защиты на обоих маршрутизаторах туннель должен подняться. Если не поднялся, отправьте трафик в сторону пира: ping 10.0.101.2 с R1.

enable
show ip interface brief | include Tunnel
show crypto ikev2 sa

Интерфейс Tunnel1 должен быть в состоянии up/up, а IKEv2 SA — в статусе READY.

Пример вывода (на R1; значения условные, формат зависит от версии):

R1#show crypto ikev2 sa
 IPv4 Crypto IKEv2 SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         203.0.113.2/500       192.0.2.66/500        none/none            READY
      Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/120 sec

Статус READY значит: IKE SA установлена. Остальные поля: fvrf/ivrf — виртуальные таблицы маршрутизации (VRF), none означает, что они не используются; PRF — функция выработки ключей; Auth sign/Auth verify — способ аутентификации (здесь общий ключ, PSK). Если вместо этого пусто или запись постоянно пропадает и появляется, смотрите разделы «Поиск проблем» и «Типичные ошибки».

Маршрутизация поверх туннеля

Сам по себе туннель только соединяет два адреса. Чтобы сети офисов пошли через него, нужны маршруты (подробно о статических маршрутах — в статье 06).

На R1 (только если GRE настраивался):

enable
configure terminal
no ip route 192.168.60.0 255.255.255.0 10.0.100.2
end

На RB (только если GRE настраивался; строки для 192.168.20.0 и 192.168.99.0 нужны, лишь если вы добавляли такие маршруты, а сообщение об отсутствии маршрута при удалении нормально и безвредно):

enable
configure terminal
no ip route 192.168.10.0 255.255.255.0 10.0.100.1
no ip route 192.168.20.0 255.255.255.0 10.0.100.1
no ip route 192.168.99.0 255.255.255.0 10.0.100.1
end

Фильтры на Tunnel1 (до добавления маршрутов)

На R1 два списка на Tunnel1. TUN1-OUT не пускает гостевую сеть в туннель, TUN1-IN не пускает филиал в гостевую сеть и сеть управления (это зеркало TUN0-IN из статьи про GRE-туннели); остальное идёт как раньше. Если вам нужно управлять R1 из филиала, строку 10 не добавляйте или замените её разрешением только для адреса рабочего места администратора. Фильтры из статьи про GRE (TUN0-IN на Tunnel0 и строки 55, 56 в GUEST-IN) продолжают работать для Tunnel0; для Tunnel1 нужны отдельные (TUN1-IN, TUN1-OUT и строка 57). Если вы добавляли строки 55 и 56, они уже запрещают гостям сеть филиала, и TUN1-OUT остаётся лишь вторым рубежом.

enable
configure terminal
ip access-list extended TUN1-OUT
 10 deny ip 192.168.20.0 0.0.0.255 any
 20 permit ip any any
exit
ip access-list extended TUN1-IN
 10 deny ip 192.168.60.0 0.0.0.255 192.168.99.0 0.0.0.255
 20 deny ip 192.168.60.0 0.0.0.255 192.168.20.0 0.0.0.255
 30 permit ip any any
exit
interface Tunnel1
 ip access-group TUN1-OUT out
 ip access-group TUN1-IN in
end

Список GUEST-IN из статьи про ACL про туннель ничего не знает, поэтому добавьте в него строку для сети 10.0.101.0/30 (номер 57, чтобы не конфликтовать со строками 55 и 56 из статьи про GRE; проверьте show ip access-lists GUEST-IN):

enable
configure terminal
ip access-list extended GUEST-IN
 57 deny ip 192.168.20.0 0.0.0.255 10.0.101.0 0.0.0.3
end

Если строк 55 и 56 из статьи про GRE у вас нет, добавьте и запрет к сети филиала: 55 deny ip 192.168.20.0 0.0.0.255 192.168.60.0 0.0.0.255. Если у вас есть второй шлюз R3 (статья про HSRP), копию GUEST-IN на нём нужно обновить так же. Как проверить: show ip interface Tunnel1 содержит Inbound access list is TUN1-IN и Outgoing access list is TUN1-OUT, а show access-lists TUN1-IN показывает рост счётчиков у 30 permit ip any any при обычной работе.

enable
configure terminal
ip access-list extended TUN1-IN
 5 permit tcp 192.168.60.0 0.0.0.255 192.168.99.0 0.0.0.255 established
 6 permit icmp 192.168.60.0 0.0.0.255 192.168.99.0 0.0.0.255 echo-reply
end

Маршруты через Tunnel1

Теперь добавляем маршруты через Tunnel1. На R1 — к сети филиала:

enable
configure terminal
ip route 192.168.60.0 255.255.255.0 Tunnel1
end

На RB — к офисной сети:

enable
configure terminal
ip route 192.168.10.0 255.255.255.0 Tunnel1
end

Сеть управления 192.168.99.0/24 добавляйте (ip route 192.168.99.0 255.255.255.0 Tunnel1 на RB) только если действительно нужно, чтобы филиал и VLAN 99 обменивались трафиком (управление оборудованием главного офиса из филиала или, наоборот, филиалом из VLAN 99: без этого маршрута ответы филиала в VLAN 99 не дойдут). В обоих случаях учтите фильтр TUN1-IN и предупреждение о нём выше.

Можно вместо интерфейса указать следующий узел (10.0.101.2 на R1 и 10.0.101.1 на RB): для туннеля «точка-точка» результат одинаков. Если сетей много, на туннеле можно включить и динамический протокол: static VTI это допускает (например, OSPF из статьи 11 или EIGRP из статьи 14); в этой статье мы ограничимся статикой.

Что насчёт NAT: если на R1 настроен выход в интернет через NAT (статья про DHCP и NAT), он применяется к трафику, идущему на интерфейс с ip nat outside. Tunnel1 таким интерфейсом не помечается, поэтому трафик в филиал идёт без трансляции с исходными адресами. Не добавляйте ip nat outside на Tunnel1.

MTU и MSS

MTU (Maximum Transmission Unit) — максимальный размер пакета, который проходит по каналу; MSS (Maximum Segment Size) — максимальный размер данных в одном TCP-сегменте. Шифрование добавляет к каждому пакету служебные данные (по оценке Cisco, до примерно 58 байт на пакет для ESP). Из-за этого большие пакеты могут не помещаться в MTU канала и теряться: ping идёт, а файлы по SMB или веб-страницы «зависают». IOS XE сам считает «plaintext mtu» (размер пакета до шифрования) и показывает его в show crypto ipsec sa. Как практическое решение (это ориентир, а не требование Cisco) на обоих концах ограничивают MSS TCP:

enable
configure terminal
interface Tunnel1
 ip tcp adjust-mss 1350
end

Команда уменьшает размер сегмента в TCP SYN, проходящих через интерфейс. Значение 1350 оставляет запас; при необходимости подберите своё. Готового числа именно для tunnel mode ipsec ipv4 в документации Cisco нет, поэтому 1350 — осторожная практическая оценка. Не переносите сюда параметры из статьи про GRE (MTU 1400 и MSS 1360 приведены Cisco для схемы GRE поверх IPsec, которую мы здесь не строим): у Tunnel0 и Tunnel1 разные накладные расходы, и значения у них могут отличаться.

Как проверить

На R1:

enable
ping 10.0.101.2
ping 192.168.60.1 source 192.168.10.1
show ip route 192.168.60.0

Первая команда проверяет сам туннель, вторая — связь между сетями (в источнике — адрес R1 в VLAN 10: если вы выполняли статью про HSRP, где реальный адрес R1 стал 192.168.10.2, подставьте его: ping 192.168.60.1 source 192.168.10.2). В таблице маршрутов должна быть строка S 192.168.60.0/24 is directly connected, Tunnel1, и это должен быть единственный путь: если рядом виден следующий узел 10.0.100.2, значит, прежний GRE-маршрут не удалён. Затем проверьте связь с настоящего компьютера из VLAN 10: ping 192.168.60.1.

В схеме с HSRP туннель и маршруты в филиал находятся только на R1, поэтому он должен быть Active (более высокий приоритет и preempt). Иначе хосты будут отправлять трафик на R3, который о филиале ничего не знает, и пинг с компьютера не пройдёт, хотя туннель исправен.

Проверка работы туннеля

Основные команды, которые стоит запомнить:

enable
show crypto ikev2 sa
show crypto ikev2 sa detailed
show crypto ipsec sa
show crypto session
show interfaces tunnel 1

IPsec SA и счётчики. В show crypto ipsec sa ищите строки #pkts encaps и #pkts decaps — число пакетов, зашифрованных и расшифрованных. Запустите ping 192.168.60.1 source 192.168.10.1 и повторите команду: оба счётчика должны расти.

Пример вывода (фрагмент; значения условные, поля зависят от версии IOS):

R1#show crypto ipsec sa

interface: Tunnel1
    Crypto map tag: Tunnel1-head-0, local addr 203.0.113.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/256/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/256/0)
   current_peer 192.0.2.66 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10
    #pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10
    #send errors 0, #recv errors 0

     local crypto endpt.: 203.0.113.2, remote crypto endpt.: 192.0.2.66
     ...
     inbound esp sas:
      spi: 0x1A2B3C4D(439041101)
        in use settings ={Tunnel, }
        Status: ACTIVE(ACTIVE)
     ...

protected vrf: (none) — VRF не используется; spi (Security Parameter Index) — номер, по которому устройство находит нужную SA среди входящих пакетов. Если encaps растёт, а decaps стоит на нуле, ваша сторона шифрует и отправляет, но от партнёра ничего не приходит: проверяйте его настройки, ACL и маршрут обратно. И наоборот. Адреса 0.0.0.0/0.0.0.0 в ident для VTI нормальны.

Сессия.

Пример вывода:

R1#show crypto session
Crypto session current status

Interface: Tunnel1
Profile: PROF-RB
Session status: UP-ACTIVE
Peer: 192.0.2.66 port 500
  Session ID: 0
  IKEv2 SA: local 203.0.113.2/500 remote 192.0.2.66/500 Active
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
        Active SAs: 2, origin: crypto map

UP-ACTIVE — туннель работает (набор строк зависит от версии; на RB в строке Profile будет PROF-R1). Слова origin: crypto map для VTI — внутреннее обозначение, это не ошибка.

Интерфейс. В show interfaces tunnel 1 должны быть строки о том, что интерфейс up, а режим и защита включены.

Пример вывода (фрагмент):

R1#show interfaces tunnel 1
Tunnel1 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 10.0.101.1/30
  ...
  Tunnel source 203.0.113.2 (GigabitEthernet0/0/0), destination 192.0.2.66
  Tunnel protocol/transport IPSEC/IP
  ...
  Tunnel protection via IPSec (profile "IPSEC-PROF")

Когда всё работает, отмените страховочную перезагрузку на обоих устройствах и сохраните настройки:

enable
reload cancel
copy running-config startup-config

Мониторить доступность туннеля удобно с помощью IP SLA (см. статью про мониторинг), а для приоритета голоса и критичного трафика внутри туннеля подойдёт QoS.

Поиск проблем

Идите сверху вниз, от простого к сложному.

1. Есть ли связь между внешними адресами? ping 192.0.2.66 с R1 (на RB — ping 203.0.113.2). Нет — проблема в маршрутах и ACL провайдерской стороны; помните, что собственный OUTSIDE-IN может блокировать ping с RB до R1.
2. Видны ли пакеты IKE? show access-lists OUTSIDE-IN — растут ли счётчики у строк с eq 500 и eq 4500.
3. Есть ли IKE SA? show crypto ikev2 sa. Если пусто — переговоры не завершились; если запись есть, но туннель не работает — смотрите show crypto ipsec sa и маршруты.
4. Растут ли счётчики? encaps без decaps — проблема на другом конце или на обратном пути.

Отладка

Если простых проверок мало, включайте отладку, но осторожно. Отладочный вывод нагружает процессор и на боевом маршрутизаторе может «залить» консоль. Сначала задайте условие с адресом партнёра (условная отладка), только потом включайте нужные debug (команда terminal monitor нужна, если вы подключены по SSH, а не через консоль):

enable
terminal monitor
debug crypto condition peer ipv4 192.0.2.66
debug crypto ikev2
debug crypto ikev2 error
debug crypto ipsec error

Условие debug crypto condition peer ... задаётся до включения отладки. В руководстве Cisco условия описаны для отладок isakmp, ipsec и engine, а для IKEv2 предусмотрено условие по имени профиля (например, debug crypto condition ikev2 PROF-RB; синтаксис проверьте подсказкой ?). Работает ли фильтр по peer для debug crypto ikev2 на вашей версии, проверяйте командой show crypto debug-condition и по объёму вывода; если сообщения идут потоком, сразу выполните undebug all. В руководстве Cisco по диагностике IKEv2 используются и более узкие варианты debug crypto ikev2 packet (обмен сообщениями) и debug crypto ikev2 internal (внутренняя логика). Закончив, обязательно отключите всё:

enable
undebug all
debug crypto condition reset

В выводе обращайте внимание на сообщения об ошибках согласования. NO_PROPOSAL_CHOSEN означает, что партнёры не нашли общих алгоритмов (несовпадение proposal или transform set). Ошибки аутентификации (например, AUTHENTICATION_FAILED) чаще всего значат неверный PSK или неверный идентификатор.

Откат

Если вы подключены через этот туннель, работайте с консоли или со страховкой reload in 30: после удаления туннеля сессия оборвётся. Если до IPsec работал GRE, верните его маршруты (см. статью про GRE) и снимите shutdown с Tunnel0, если вы его делали (если вы удалили Tunnel0 командой no interface Tunnel0, его придётся создать заново по статье про GRE).

Чтобы убрать туннель, на каждом маршрутизаторе удалите интерфейс и маршруты и затем профили:

enable
configure terminal
no ip route 192.168.60.0 255.255.255.0 Tunnel1
no interface Tunnel1
no crypto ipsec profile IPSEC-PROF
no crypto ipsec transform-set TS-AES256-SHA256
no crypto ikev2 profile PROF-RB
no crypto ikev2 keyring KR-RB
no crypto ikev2 policy POL-LAB
no crypto ikev2 proposal PROP-AES256
end

Команды даны для R1; на RB имена профиля и keyring другие (PROF-R1, KR-R1), а вместо маршрута к 192.168.60.0 удалите маршрут к 192.168.10.0 через Tunnel1 (и к 192.168.99.0, если добавляли). Если вы добавляли ACL TUN1-OUT и TUN1-IN, сначала снимите их с интерфейса (это делает no interface Tunnel1), затем удалите командами no ip access-list extended TUN1-OUT и no ip access-list extended TUN1-IN. Строку 57 из GUEST-IN удалите (no 57 в режиме ip access-list extended GUEST-IN); строки 55 и 56 относятся к статье про GRE, и пока работает Tunnel0, их оставляют. Строки ACL, добавленные для IKE и ESP, удалите отдельно (no 4, no 5, no 6 в режиме ip access-list extended OUTSIDE-IN; сверьте номера с show ip access-lists OUTSIDE-IN, если подбирали другие).

Справка: ключ, сертификаты и smart defaults

Пароль и сертификаты

Для двух офисов общий ключ (PSK) — самый простой способ аутентификации. Ключ должен быть длинным и случайным и одинаковым на обеих сторонах. В running-config он может отображаться открытым текстом, поэтому считайте любую копию конфигурации секретной и защищайте резервные копии (см. статью про резервное копирование).

В справочнике команд crypto ikev2 keyring для ключа указан необязательный признак 0 (открытый текст) или 6 (зашифрованный ключ). Более надёжное шифрование ключей (тип 6) упомянуто в статье про AAA; поддержку на вашей платформе и версии проверьте подсказкой ?.

Если филиалов много, лучше использовать сертификаты (инфраструктуру открытых ключей, PKI): не нужно менять ключ на всех устройствах при компрометации одного. Настройка PKI выходит за рамки этой статьи.

Smart defaults

Если не создавать собственные proposal и policy, IKEv2 на IOS XE использует встроенные настройки (smart defaults). В них, в зависимости от версии, встречаются и устаревшие варианты (DH-группа 5), и более слабая по современным меркам целостность esp-sha-hmac (на основе SHA-1). Просмотреть их можно командами show crypto ikev2 proposal default, show crypto ikev2 policy default и show crypto ipsec profile default; в show running-config они не видны, только в show running-config all. Cisco не рекомендует их менять, поэтому в нашей настройке мы просто задаём собственные proposal, policy и transform set явно, чтобы результат не зависел от версии.

Типичные ошибки

• Несовпадающие proposal или transform set. Шифрование, целостность, DH-группа или режим на двух сторонах отличаются. Симптом: NO_PROPOSAL_CHOSEN в отладке, IKE SA нет. Сверьте блоки построчно (show running-config | section crypto).
• Не совпадает ключ или адреса в keyring/profile. PSK должен быть одинаковым, а в keyring и match identity remote address на каждой стороне должен стоять адрес именно партнёра, а не свой. Часто путают стороны в tunnel destination: на R1 это адрес RB, а на RB — адрес R1; tunnel source — собственный внешний интерфейс. Профиль IKEv2 без match identity игнорируется.
• ACL режет UDP 500, UDP 4500 или ESP. IKE не доходит или доходит, а ESP-пакеты блокируются. Проверьте правила на обоих внешних интерфейсах и у провайдера, а также переключение на порт 4500 при NAT.
• Маршрут к адресу пира идёт в туннель. Туннель поднимается и сразу падает. Убедитесь, что show ip route 192.0.2.66 выходит через WAN.
• Неверные маршруты. Если забыли обратный маршрут на RB или сети VLAN на R1, IKE и ESP работают, ping 10.0.101.2 успешен, но пинг из LAN не проходит (encaps растёт, decaps на другой стороне нет). Если остались маршруты через Tunnel0 после статьи про GRE, трафик делится между GRE и IPsec и часть идёт без шифрования: в show ip route 192.168.60.0 должен быть только Tunnel1. Гостевую сеть явно запретите ACL: туннель сам ничего не фильтрует.
• Размеры пакетов. Ping проходит, а передача больших данных виснет: проверьте ip tcp adjust-mss на туннеле.

Что дальше

• Cisco с нуля 17. GRE-туннели: туннель без шифрования, нужен для протоколов с multicast и сложных схем. Туннель Tunnel1 из этой статьи заменяет GRE для задачи «защищённый канал в филиал»; GRE поверх IPsec здесь не разбирается.
• Cisco с нуля 19. QoS: основы MQC: приоритет голоса и критичного трафика в туннеле.
• Cisco с нуля 23. Межсетевой экран на маршрутизаторе: ZBFW: как защитить маршрутизатор и не заблокировать собственный VPN.
• Настройка IPsec на Cisco: старый способ на crypto map.