Site-to-site VPN (IPsec) между двумя офисами

Когда у компании появляется филиал, вопрос связи между офисами встаёт быстро. Арендовать выделенный канал дорого, а гонять чувствительный трафик через интернет в открытом виде — небезопасно. Site-to-site VPN на базе IPsec решает эту задачу: два маршрутизатора на границе сетей шифруют весь трафик между офисами, и для пользователей это выглядит так, будто оба офиса находятся в одной сети.

В этой статье настроим IPsec-туннель между головным офисом с маршрутизатором rtr-edge01 (сеть 192.168.10.0/24, домен itpages.lab.local) и филиалом с маршрутизатором rtr-branch01 (сеть 192.168.20.0/24). Оба маршрутизатора смотрят в интернет публичными адресами: у rtr-edge01 это 203.0.113.10, у rtr-branch01 — 198.51.100.20.

Настройка IKE Phase 1 (ISAKMP)

IPsec строится в два этапа. Первый — IKE Phase 1, где стороны договариваются, как будут аутентифицировать друг друга и как защитят сам канал согласования параметров, прежде чем начнётся передача какого-либо реального пользовательского трафика.

rtr-edge01# configure terminal
rtr-edge01(config)# crypto isakmp policy 10
rtr-edge01(config-isakmp)# encryption aes 256
rtr-edge01(config-isakmp)# hash sha256
rtr-edge01(config-isakmp)# authentication pre-share
rtr-edge01(config-isakmp)# group 14
rtr-edge01(config-isakmp)# lifetime 86400
rtr-edge01(config-isakmp)# exit

rtr-edge01(config)# crypto isakmp key VpnSharedKey2026! address 198.51.100.20

Параметры политики (шифрование, хэш, группа Диффи-Хеллмана, время жизни) должны совпадать на обоих маршрутизаторах — IOS согласует их автоматически, но только если хотя бы одна политика на каждой стороне совпадает полностью. Общий ключ (pre-shared key) должен быть идентичным на обеих сторонах и привязан к публичному адресу удалённого маршрутизатора.

На rtr-branch01 настройка зеркальная, с адресом головного офиса:

rtr-branch01# configure terminal
rtr-branch01(config)# crypto isakmp policy 10
rtr-branch01(config-isakmp)# encryption aes 256
rtr-branch01(config-isakmp)# hash sha256
rtr-branch01(config-isakmp)# authentication pre-share
rtr-branch01(config-isakmp)# group 14
rtr-branch01(config-isakmp)# lifetime 86400
rtr-branch01(config-isakmp)# exit

rtr-branch01(config)# crypto isakmp key VpnSharedKey2026! address 203.0.113.10

Настройка IKE Phase 2 (IPsec transform-set)

Phase 2 определяет, как именно будет защищён сам пользовательский трафик внутри туннеля — какой протокол и алгоритм шифрования применяются к данным после того, как канал согласования уже установлен.

rtr-edge01(config)# crypto ipsec transform-set TS-VPN esp-aes 256 esp-sha256-hmac
rtr-edge01(cfg-crypto-trans)# mode tunnel
rtr-edge01(cfg-crypto-trans)# exit

mode tunnel означает, что шифруется весь исходный IP-пакет целиком, включая заголовок, а поверх добавляется новый заголовок для передачи между публичными адресами маршрутизаторов — это стандартный режим для site-to-site VPN, в отличие от transport mode, который применяется в других сценариях.

Определение интересного трафика

VPN-туннель поднимается не для всего трафика подряд, а только для того, что должен идти между двумя конкретными сетями. Это определяется через ACL — тот же механизм, что мы разбирали в статье про списки доступа.

rtr-edge01(config)# ip access-list extended VPN-TRAFFIC
rtr-edge01(config-ext-nacl)# permit ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255
rtr-edge01(config-ext-nacl)# exit

На rtr-branch01 список должен быть зеркальным — источник и назначение меняются местами:

rtr-branch01(config)# ip access-list extended VPN-TRAFFIC
rtr-branch01(config-ext-nacl)# permit ip 192.168.20.0 0.0.0.255 192.168.10.0 0.0.0.255
rtr-branch01(config-ext-nacl)# exit

Crypto map и применение на интерфейсе

rtr-edge01(config)# crypto map VPN-MAP 10 ipsec-isakmp
rtr-edge01(config-crypto-map)# set peer 198.51.100.20
rtr-edge01(config-crypto-map)# set transform-set TS-VPN
rtr-edge01(config-crypto-map)# match address VPN-TRAFFIC
rtr-edge01(config-crypto-map)# exit

rtr-edge01(config)# interface gigabitEthernet 0/1
rtr-edge01(config-if)# crypto map VPN-MAP
rtr-edge01(config-if)# exit

Crypto map связывает воедино адрес удалённого пира, набор параметров шифрования (transform-set) и список интересного трафика, а затем применяется на внешний интерфейс, через который туннель выходит в интернет — в данном случае тот же gigabitEthernet 0/1, что использовался под NAT в предыдущей статье серии.

NAT exemption: важная деталь

Если на маршрутизаторе уже настроен NAT для выхода в интернет (как в предыдущей статье), трафик между офисами тоже может случайно попасть под трансляцию адресов — а VPN-туннель ожидает видеть реальные внутренние адреса по обе стороны, а не транслированные. Нужно явно исключить трафик к филиалу из NAT.

rtr-edge01(config)# ip access-list extended NAT-EXEMPT
rtr-edge01(config-ext-nacl)# deny ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255
rtr-edge01(config-ext-nacl)# permit ip 192.168.10.0 0.0.0.255 any
rtr-edge01(config-ext-nacl)# exit

rtr-edge01(config)# ip nat inside source list NAT-EXEMPT interface gigabitEthernet 0/1 overload

Этот ACL нужно использовать вместо старого списка в команде ip nat inside source list — он говорит: трафик к сети филиала (192.168.20.0/24) не транслировать, а весь остальной трафик — транслировать как обычно через overload.

Dead Peer Detection: обнаружение обрыва канала

Если интернет-канал на одной из сторон падает без явного сигнала (например, обрыв провода у провайдера, а не аккуратное отключение оборудования), маршрутизатор с другой стороны может долго считать туннель рабочим и продолжать отправлять в него трафик, который никуда не доходит. DPD (Dead Peer Detection) решает эту проблему — маршрутизаторы периодически проверяют, жив ли собеседник.

rtr-edge01(config)# crypto isakmp keepalive 10 3

Эта команда включает keepalive-проверки каждые 10 секунд с тремя повторами перед тем, как считать пира недоступным. Значение стоит подбирать по балансу: слишком частые проверки создают лишнюю служебную нагрузку, слишком редкие — задерживают обнаружение реального обрыва и переключение на резервный маршрут, если он есть.

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

rtr-edge01# show crypto isakmp sa
rtr-edge01# show crypto ipsec sa
rtr-edge01# ping 192.168.20.1 source 192.168.10.1

show crypto isakmp sa должна показать состояние QM_IDLE — это значит, что Phase 1 успешно согласован и стабилен. show crypto ipsec sa покажет счётчики зашифрованных и расшифрованных пакетов — если оба счётчика растут при тестовом трафике, туннель реально передаёт данные, а не просто числится поднятым. Туннель в IOS по умолчанию поднимается только при появлении интересного трафика, поэтому первый пинг может пройти с задержкой или даже потеряться, пока идёт согласование Phase 1 и Phase 2.

Мониторинг состояния туннеля через SLA tracking

Site-to-site VPN обычно строится на статических маршрутах в сторону удалённой сети — но статический маршрут сам по себе не знает, что туннель упал, и продолжает считать путь рабочим, даже когда трафик в него уходит в никуда. IP SLA с отслеживанием (tracking) позволяет автоматически убирать маршрут из таблицы, если удалённая сторона перестала отвечать.

rtr-edge01(config)# ip sla 1
rtr-edge01(config-ip-sla)# icmp-echo 192.168.20.1 source-ip 192.168.10.1
rtr-edge01(config-ip-sla)# frequency 10
rtr-edge01(config-ip-sla)# exit
rtr-edge01(config)# ip sla schedule 1 life forever start-time now

rtr-edge01(config)# track 1 ip sla 1 reachability

rtr-edge01(config)# ip route 192.168.20.0 255.255.255.0 198.51.100.20 track 1

Пока пинг до 192.168.20.1 проходит каждые 10 секунд, маршрут остаётся активным. Как только удалённая сторона перестаёт отвечать, объект tracking переходит в состояние down, и маршрутизатор автоматически убирает статический маршрут из таблицы — это особенно полезно, если в сети есть резервный путь (например, через второй интернет-канал или резервный VPN), на который трафик должен переключиться при обрыве основного туннеля.

GRE поверх IPsec для динамической маршрутизации между офисами

Классический IPsec-туннель на crypto map, который мы настроили выше, отлично шифрует трафик, но не умеет передавать через себя протоколы динамической маршрутизации или multicast — он работает по принципу «интересный трафик по ACL», а не как обычный сетевой интерфейс. Если офисов становится больше двух и маршруты между ними нужно поддерживать автоматически, поверх IPsec часто поднимают GRE-туннель — тогда шифрование берёт на себя IPsec, а маршрутизацию и гибкость — обычный туннельный интерфейс.

rtr-edge01(config)# interface tunnel 1
rtr-edge01(config-if)# ip address 10.255.255.1 255.255.255.252
rtr-edge01(config-if)# tunnel source gigabitEthernet 0/1
rtr-edge01(config-if)# tunnel destination 198.51.100.20
rtr-edge01(config-if)# tunnel protection ipsec profile GRE-PROTECT
rtr-edge01(config-if)# exit

В этой схеме crypto map на физическом интерфейсе больше не нужен — шифрование навешивается прямо на туннельный интерфейс через tunnel protection, а трафик, интересный для VPN, определяется уже не списком доступа, а таблицей маршрутизации, как для любого обычного интерфейса. Для связи всего двух офисов, как в примере этой статьи, простой crypto map обычно достаточен и проще в обслуживании — GRE поверх IPsec стоит рассматривать, когда офисов становится больше или когда через туннель нужно пускать что-то помимо обычного IP unicast трафика.

Проверка состояния туннеля и типичные команды диагностики

После того как IPsec-туннель поднят, полезно держать под рукой набор команд для быстрой диагностики — особенно если офисы жалуются на периодические обрывы связи. На rtr-edge01 в первую очередь смотрят на фазу 1 (ISAKMP SA) и фазу 2 (IPsec SA):

rtr-edge01# show crypto isakmp sa
rtr-edge01# show crypto ipsec sa
rtr-edge01# show crypto session

Если ISAKMP SA есть, а IPsec SA отсутствует — проблема почти всегда в transform-set или в access-list, который определяет интересный трафик (interesting traffic). Если туннель поднимается, но рвётся каждые несколько минут — проверь таймеры keepalive DPD (dead peer detection) и убедись, что они одинаковы на обеих сторонах. Несовпадение MTU тоже частая причина: пакеты с ESP-заголовком крупнее обычных, и если где-то по пути фрагментация запрещена, часть трафика будет просто теряться.

Частые ошибки и как их избежать

• Несовпадающие параметры ISAKMP-политики. Даже небольшое расхождение — другая группа Диффи-Хеллмана или другой алгоритм хэширования — не даст Phase 1 согласоваться, и в логах появится что-то вроде %CRYPTO-4-IKMP_NO_POLICY. Все параметры политики должны буквально совпадать на обеих сторонах.
• Забыли про NAT exemption. Если трафик к филиалу проходит через обычный NAT overload, адреса подменяются до того, как пакет попадёт под crypto map, и туннель либо не поднимется, либо начнёт шифровать не те адреса, которые ожидает удалённая сторона. Это одна из самых частых причин, почему VPN между офисами «не видит» друг друга при уже настроенном NAT.
• Ассиметричные ACL интересного трафика. Если список на rtr-edge01 разрешает 192.168.10.0/24 -> 192.168.20.0/24, а на rtr-branch01 не настроен зеркальный список с обратным направлением, туннель может подняться, но трафик пойдёт только в одну сторону. Всегда проверяй оба конца туннеля симметрично.
• Публичный адрес филиала выдан провайдером динамически. Site-to-site VPN на pre-shared ключах, привязанных к конкретному адресу (crypto isakmp key ... address ...), сломается при первой же смене внешнего адреса на стороне филиала, если провайдер не гарантирует статический IP. Перед проектированием туннеля обязательно уточни у провайдера, статический адрес выделен филиалу или динамический — во втором случае потребуется динамическая привязка ключа (wildcard) или DNS-имя вместо адреса.

Автор — Команда IT-Pages