Чистый IPSec туннель на swanctl

Как ни странно, оказывается ничего не стоит на месте, всё течёт, всё меняется! Следующий пример как раз про это.

Была у меня значит сетевая взаимосвязанность с коттеджем в соседнем городе, в виде IP-IP туннеля. Трафик бегал в открытую, не шифровался. Вроде скрывать нечего. Основное - это RTSP-поток с камер. Решил я значит навесить шифрование. Не думаю, что товарищ майор пристально бдит за моими данными, ну а вдруг =)

Для реализации задуманного мною был выбран чистый IPSec, потому как если его накладывать на IPIP-туннель, будет лишняя сущность утилизирующая мощностя, которая в данном случае мне нахуй не нужна. Поэтому…

…удаляем, что у нас там есть в system-networkd касаемо IPIP и погнали ваять секурный туннель.

Сперва ставим старый-добрый strongswan. По пути он подтянет все необходимые зависимости

apt install strongswan

И тут столкнулись с тем, что реализация в файлах ipsec.conf перешла в статус deprecated и на сегодняшний, день было бы здорово, стильно-модно-молодёжно, замотороить это всё в swanctl.conf

Открываем файл /etc/swanctl/conf.d/tunnel.conf и рисуем следующий конфиг

connections {
    tunnel {
        version = 2
        mobike = no

        local_addrs = внешний статический IP
        remote_addrs = внешний статический IP другой стороны

        proposals = aes256gcm16-prfsha512-ecp521,aes256gcm16-prfsha384-ecp384
        reauth_time = 43200

        dpd_delay = 20s
        dpd_timeout = 60s
        
        local {
            auth = psk
            id = %addr
        }

        remote { 
            auth = psk
            id = IP той стороны
        }

        children {
            tunnel-name {
                mode = tunnel
                local_ts = Внутренняя сеть этой стороны
                remote_ts = Внутренняя сеть той стороны

                start_action = start
                rekey_time = 21600

                esp_proposals = aes128gcm16-prfsha256-x25519
            }
        }
    }
}

secrets {
    ike-tunnel {
        id-1 = %addr
        id-2 = IP той стороны
        secret = "6530772fda008486593578315c9077813b2cc7f3ec72846c815380ac35c2da72"
   }
}

Все параметры подробно описаны в офдоке, но по некоторым, которые нас интересуют, давайте пробежимся:

connections - определение подключений
tunnel - произвольное название туннеля
version - явное указание версии протокола IKE для установки соединения
mobike - в нашем случае туннель точка<->точка, поэтому выключаем
local_addrs - внешний IP с которого инициализируется IKE-соединение
remote_addrs - внешний IP удалённого IKE-пира
proposals - фаза 1 предлагающая комбинацию алгоритмов для шифрования, аутентификации и обмена ключами
reauth_time - время (в секундах), по истечении которого происходит переаутентификация IKE SA
dpd_delay - интервал отправки запросов на наличие активности пира
dpd_timeout - время ожидания ответа
local - описание параметров локальной стороны
auth - в нашем случае расшаренный ключ
id - возьмёт IP подключения
remote - описание параметров удалённой стороны. auth аналогичен, а id лучше прописать IP адрес той стороны
children - определяет параметры туннеля, что и как будет шифроваться
tunnel-name - произвольное наименование
mode - режим туннеля
local_ts - локальная сеть этой стороны
remote_ts - локальная сеть той стороны
start_action - управление запуском. В нашем случае сразу после загрузки конфигурации
rekey_time - обновляет ключи шифрования без перезапуска фазы
esp_proposals - алгоритмы шифрования и аутентификации для фазы 2
secrets - определение предрасшаренных ключей ike-tunnel - произвольное название
id-1 - берём значение из local
id-2 - берём значение из remote
secret - парольная фраза