Route-based IPSEC VPN между Ubuntu 18.04 (libreswan) и Cisco Router. Часть 2

В этой статье (часть первую можно прочитать здесь) я опишу процесс настройки Cisco роутера на примере Cisco ISR 4331 для целей создания нашего VPN-соединения. Как мы помним, конечная цель настройки — отправлять интересующий нас трафик через VPN-туннель.

Для примера, я опишу настройку Cisco для отправки всего трафика к определенным серверам через туннель (например, для обхода блокировок по стране). Начнем с создания object-group — так в дальнейшем будет проще добавлять новые адреса назначения и сразу добавим туда адрес сервера, к которому надо ходить через туннель:

object-group network TOVPN
 host 3.3.3.3

Далее создаем ip access-list, которым мы будем ловить интересующий нас трафик:

ip access-list extended TOVPN
 permit ip any object-group TOVPN

Переходим к непосредственной настройке VPN:

crypto keyring VPN
 pre-shared-key address 11.11.11.11 key %908A2R5vX9O694aoxh1

crypto isakmp profile VPN
 keyring VPN
 match identity address 11.11.11.11 255.255.255.255

crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac
 mode tunnel

crypto ipsec profile VPN
 set transform-set ESP-AES256-SHA1

crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 5

В этом коротком и всем понятном блоке указаны все необходимые данные по нашему VPN-соединению (в соответствии с первой частью статьи).

Далее необходимо создать виртуальный интерфейс, через который мы будем делать туннель.

interface Tunnel0
 ip address 172.16.0.21 255.255.255.252
 tunnel source 22.22.22.22
 tunnel mode ipsec ipv4
 tunnel destination 11.11.11.11
 tunnel protection ipsec profile VPN
 ip tcp adjust-mss 1300

Для корректной передачи данных по туннелю, чтобы в стандартный MTU пролазил пакет с «оберткой IPSEC» — нам необходимо ограничить размер MTU на интерфейсе. Делается это командой ip tcp adjust-mss MTU. В данном примере установлен MTU — 1300. Число 1300 не подбиралось экспериментальным путем, а было установлено таким, чтобы точно подходило в любых конфигурациях. На самом деле, вам, скорее всего, достаточно будет указать 1376. Если этого не сделать — обратный трафик будет проходить «частично». Если быть более точным — другой конец нашего туннеля при получении «ответных» пакетов (на наш трафик через туннель) «нормального» размера (т.е. 1476 байт) не сможет отправить их через туннель из-за превышения размера MTU. При этом мелкие пакеты будут бегать туда-сюда без особых проблем. Например, пинг и трэйсроут будут показывать наличие связи, а странички из интернета грузиться не будут.

Итак, туннель поднят, осталось отправить в него трафик. Для этого задействуем route-map:

route-map LOCAL permit 10
 match ip address TOVPN
 set interface Tunnel0

Не забываем применить этот route map к интерфейсу, к которому подключена локальная сеть.

Если все сделано по инструкции, но туннель не поднялся, проверяем:
— разрешен ли доступ снаружи к маршрутизатору по протоколам udp и gre;
— разрешен ли маршрутизатору доступ в сеть по протоколам udp и gre;

Если туннель поднялся, но трафик в него не ходит (или обратно не приходит):
— пробуем сделать ipsec restart на сервере с ubuntu;
— проверяем правила доступа с интерфейса Tunnel0 и на него (выбрана ли правильная зона для ZBFW при его использовании).

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *