CISCO IPsec часть 4 — сведём все полученные ранее знания вместе и напишем боевой конфиг для продакшена.
Пора добавить реальный, боевой конфиг. Некий офис, предполагаем весь трафик, включая выход в интернет для пользователей, через туннель (для централизации безопасности через магистральные NGFW). Теория для IKEv2 здесь.
Добавляем VRF
Выделим интернет-интерфейс роутера в отдельный VRF, что позволит разделить таблицу маршрутизации.
!
vrf definition WAN
description ISP RED
rd 65000:1
!
address-family ipv4
exit-address-family
!
interface GigabitEthernet0/0/0
description ISP RED
vrf forwarding WAN
ip address 5.5.5.5 255.255.255.0
negotiation auto
no cdp enable
no lldp transmit
!
ip route vrf WAN 0.0.0.0 0.0.0.0 5.5.5.254
!
Определяем VRF:
Route-distinguisher (RD) — уникальное число, для различия маршрутов в таблице маршрутизации, к какому VRF какой маршрут принадлежит, назначается произвольно.
В интерфейсе у нас команда vrf forwarding, которая определяет этот интерфейс в VRF. И вешаем дефолт на транспортный адрес провайдера.
Задаём ограничение для доступа
Примерно вот так:
!
no ip http server
no ip http secure-server
!
ip access-list extended internet-filter-in
10 permit tcp 2.2.2.0 0.0.0.255 host 5.5.5.5 eq 22
!
ip access-list standard 10
10 permit 10.15.0.0 0.0.255.255
!
!
line vty 0 4
access-class 10 in
access-class internet-filter-in in vrfname WAN
login local
transport input ssh
line vty 5 15
access-class 10 in
access-class internet-filter-in in vrfname WAN
login local
transport input ssh
!
Мы создали два ACL и добавили их оба на доступ к консоли SSH. Для интернета у нас прописан доступ с PI-адресов нашей компании (2.2.2.0 0.0.0.255), а для доступа из внутренней сети из сетки менеджмента (10.15.0.0 0.0.255.255).
Настройки шифрования IPsec IKEv2
Последовательно создаём конфиг для шифрования туннеля ikev2 proposal, ikev2 policy, ikev2 keyring, ikev2 profile, ipsec transform-set, ipsec profile:
!
crypto ikev2 proposal IKEv2-proposal-Branch33
encryption aes-cbc-256 aes-cbc-192 aes-cbc-128
integrity sha512 sha384 sha256
group 20 14
!
crypto ikev2 policy IKEv2-policy-Branch33
match fvrf WAN
proposal IKEv2-proposal-Branch33
!
crypto ikev2 keyring KR-Branch33
peer R1
address 2.2.2.21
pre-shared-key local QCJaiXmMyMngu7Fkz37x
pre-shared-key remote QCJaiXmMyMngu7Fkz37x
!
!
crypto ikev2 profile IKEv2-profile-Branch33
match fvrf WAN
match identity remote address 2.2.2.21 255.255.255.255
authentication remote pre-share
authentication local pre-share
keyring local KR-Branch33
dpd 10 2 on-demand
!
!
crypto ipsec transform-set TS-Branch33 esp-aes 256 esp-sha384-hmac
mode transport
!
crypto ipsec profile IPsec-profile-Branch33
set transform-set TS-Branch33
set ikev2-profile IKEv2-profile-Branch33
!
Цветом выделил строки, где нужно подпихнуть VRF, иначе не заработает.
Туннельный интерфейс
Создаём интерфейс и вешаем на него профиль:
!
interface Tunnel50
description TO_DataCenter
ip address 10.10.10.2 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source GigabitEthernet0/0/0
tunnel destination 2.2.2.21
tunnel vrf WAN
tunnel protection ipsec profile IPsec-profile-Branch33
!
Типовые рекомендуемые настройки, tunnel vrf означает, что данные для сурса и дестинейшена туннеля надо искать с учётом VRF. И ещё тут одна вещь, какой режим для transform-set ни выставляй, при просмотре интерфейса:
Encapsulation TUNNEL, loopback not set
Но там же эффективное MTU для туннеля при этом различается. Для настройки mode transport:
Tunnel transport MTU 1418 bytes
А для mode tunnel:
Tunnel transport MTU 1398 bytes
Не углублялся в расследование этого момента и насколько это правдиво, надо смотреть в лабе. Работает и так, и так.
Маршрут
Если у нас на бранч-офисе один роутер и один туннель, проще всего повесить статику (с обеих сторон):
!
ip route 0.0.0.0 0.0.0.0 10.10.10.1 name TO_DataCenter
!
Приглашаю поделиться мнением в Tелеграм канал