Ubuntu 11.04 настройка IPsec (ipsec-tools, racoon). Точка — сеть
Настраивался VPN-туннель между сетями:
src: 70.108.83.52/29
peer: 210.152.129.234/32
dst: 210.65.95.200/32
Рассчитать длину маски подсети можно с помощью калькулятора:
http://www.ip-ping.ru/netcalc/
Устанавливаем racoon и ipsec-tools
apt-get install racoon ipsec-tools
Настраиваем racoon:
nano -u /etc/racoon/racoon.conf (Ключь -u позволяет делать отмену изменений по нажатию Alt+u)
path pre_shared_key «/etc/racoon/psk.txt»;
remote 210.152.129.234 <
exchange_mode main;
lifetime time 28800 sec;
proposal <
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2;
>
sainfo address 70.108.83.53/32 any address 210.65.95.200/32 any <
pfs_group 2;
lifetime time 3600 sec;
encryption_algorithm 3des;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
>
Внимательно указываем все параметры шифрования. Для успешного установления канала, на стороне src и peer они должны быть идентичными!
В секции remote устанавливаются параметры phase1. В секции sainfo — phase2.
Настраиваем ipsrc-tools.conf:
nano -u /etc/ipsec-tools.conf
#Указываем сети, между которыми осуществляется шифрование, туннель и тип шифруемого трафика.
spdadd 70.108.83.53/32 210.65.95.200/32 any -P out ipsec
esp/tunnel/70.108.83.53-210.152.129.234/require;
spdadd 210.65.95.200/32 70.108.83.53/32 any -P in ipsec
esp/tunnel/210.152.129.234-70.108.83.53/require;
Вносим ключ шифрования для peer:
nano -u /etc/racoon/psk.txt
210.152.129.234 a9993e364706816aba3e
Перезапускаем службы:
/etc/init.d/setkey restart && /etc/init.d/racoon restart
В случае ошибки, смотрим логи:
tail -100 /var/log/syslog
Добавляем маршрут, заворачивающий пакеты идущие к 210.65.95.200 в туннель.
ip route add to 210.65.95.200/32 via 70.108.83.53 src 70.108.83.53
Проверяем маршрут:
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
212.65.95.200 70.108.83.53 255.255.255.255 UGH 0 0 0 eth0
70.108.83.48 * 255.255.255.248 U 0 0 0 eth0
192.168.0.0 * 255.255.255.0 U 0 0 0 eth1
default 70.108.83.49 0.0.0.0 UG 0 0 0 eth0
Добавляем установку маршрута в скрипты запуска сетевых интерфейсов:
nano -u /etc/network/interfaces
auto eth0
iface eth0 inet static
address 70.108.83.53
netmask 255.255.255.248
post-up route add default gw 70.108.83.49 eth0
post-up ip route add to 210.65.95.200/32 via 70.108.83.53 src 70.108.83.53
Туннель устанавливается в момент первого обращения, поэтому запускаем:
telnet 210.65.95.200 22
Ctrl+c
Смотрим создаётся ли туннель:
setkey -D
В случае ошибки, смотрим логи:
tail -100 /var/log/syslog
Источник
Racoon
Содержание
Racoon (VPN IPSec) сервер
Racoon позволяет осуществлять VPN-соединения типа «транспорт» или «туннель» между компьютерами и целыми подсетями. Представляет собой собственно сервис для осуществления первой фазы соединения и задания правил фазы 2. Основных утилит по работе с VPN-соединением две: racoonctl и setkey, функционал которых несколько пересекается. Команда racoon — собственно демон — ожидает подключений или осуществляет подключение сам. После обмена данными по выбору шифрования и подтверждения ключевой фразы (пароль) создает cookie соединения, который используется при переподключении в «времени жизни» этого самого cookie. Далее в ход вступают правила, настроенные через setkey — это фактически инструкции для изменения маршрутов. Приведем несколько полезных команд.
(Бес)Полезные команды
- /etc/init.d/racoon start|stop|restart|status — позволяет управлять службой, но делать это стоит крайне осторожно, дело в том, что рестарт этой службы обрубит соединения и вычистит куки, сохраненные после фазы 1. Может так получиться, что вторая сторона будет продолжать их использовать (и, следовательно, требовать) при попытке снова подключиться (вместо полноценной процедуры обмена сертификатами и пр.), что помешает восстановить соединение, пока, например, второй сервер не будет перезапущен тоже. Кстати, информативность сообщений о такой ошибке будет. никакой.
- racoonctl reload-config — без разрыва имеющихся соединений позволяет применить новые настройки — рекомендуется использовать вместо рестарта службы, чтобы перечитать настройки.
- racoonctl vpn-connect|vpn-disconnect — явная попытка подключиться. Замечу, что при правильной настройке такое подключение осуществляется неявно при любом запросе удаленной стороны (ping, ssh и т.п.). Команды малополезны: об ошибках они НЕ сообщают. Удобны, чтобы сразу после их выполнения смотреть все ошибки в /var/log/messages.
- setkey -DP — показывает «шаблоны» соединений (должны быть нетривиальные записи даже до установленного соединения).
- setkey -DH (полный аналог: racoonctl show-sa ipsec) — показывает установленные соединения (обычно парами: из А в В, из В в А) с некоторой статистикой. Замечены дублирующиеся записи (порты, например, могут быть разные), но это не влияло на работоспособность.
- racoonctl show-sa isakmp — показывает сохраненные куки для соединений (результат фазы 1)
Требования к ядру
При использовании OpenVZ выяснилось, что на хостовой машине потребовалась загрузка дополнительных модулей, а именно:
- af_key
- xfrm4_tunnel
- authenc
- xfrm4_mode_tunnel
- esp4
Возможно, не все они обязательны, но зато наверняка.
Настройка racoon
Основной файл настроек /etc/racoon.conf:
Выше приведен действующий ныне файл настройки racoon’a (показаны настройки соединения только с одним хостом и «всеми остальными»). Кратко о параметрах:
- path pre_shared_key: здесь хранятся пароли для соединения с хостами. Сам файл должен иметь разрешение 600 (владелец root:root). Указанные ip проверяются по очереди сверху вниз, поэтому запись «для всех остальных» нужно помещать внизу списка. Полагаю ip вида 123.123.123.0/24 тоже принимаются. Отметим сразу, что ключевым ip здесь выступает именно внешний ip удаленного сервера, а не внутренние. Формат записей:
- listen : способ «идентификации» демона (их может быть несколько), нужен для явного способа управления через racoonctl. Оказалось, что при компиляции racoon’а требуется включение опции —enable-adminport=yes
- remote (или anonymous для всех): блок настроек относящихся к соединению с определенным хостом (или всеми) независимо от того, какая сторона инициировала соединение.
- exchange_mode: main или aggressive (можно указать оба через запятую). Второй используется при соединениях с серыми оконечными ip, делая меньше запросов. Есть подозрение, что именно в этом режиме возникает вышеуказанная проблема с «недостертыми» cookies. По возможности рекомендуется применять Main.
- proposal_check: принимать ли «пропозалы», если их времена жизни не совпадают, возможно, exact — наилучший вариант.
- proposal : блок допустимых параметров криптования, обе стороны должны договориться, какое шифрование использовать. Допустимые можно перечислять через запятую. Главное, чтобы по всем четырем параметрам нашлись совпадающие. В РФ запрещено применение более стойких алгоритмов, чем des (3des, aes и т.д.), поэтому в официальных роутерах Zyxel доступен только des. (Во всякой китайщине, в т.ч. TPLink можно выбирать все, что душе угодно). Еще приведу синонимы для параметра длины ключа
| Zyxel | Racoon | Комментарий |
| DH1 | modp768 | Считается небезопасным — не рекомендован к применению, в StrongSWAN поэтому поддержки нет |
| DH2 | modp1024 | |
| DH5 | modp1536 | Чем длиннее, тем медленнее обработка пакетов — упоминалось значительное снижение скорости обработки пакетов |
- authentication_method: будем авторизовываться по фразе из psk.txt
- nat_traversal: on или off — проверка, за NAT’ом ли конечная цель. Отключать нужно только в случае возникновения проблем.
- sainfo : Блоки, на основании которых генерируются правила маршрутизации. Хм. Не заметил, чтобы их указания было достаточно без дополнительных команд через setkey. И наличие их необходимо. Так что нужно писать два блока «туды-сюды» (да, с повторением параметров шифрования, без этого — не работало. Подозреваю, что эти записи используются на второй фазе, а предыдущие — на первой), за исключением последнего для всех: там достаточно одной записи.
- lifetime time: (именно с пробелом, а не подчеркиванием) время действия cookies — важный параметр, желательно совпадение на обеих сторонах (см. параметр proposal_check).
Использование setkey
Вышеуказанных настроек достаточно, чтобы проводить первую фазу соединения, но недостаточно, чтобы получить фактический обмен пакетами по этому протоколу, поэтому нужно применить настройки, указанные в файле через команду (от root’а):
При (пере)запуске службы racoon, автоматом считываются настройки из /etc/racoon/setkey.conf (это можно увидеть в скрипте /etc/init.d/racoon), поэтому рекомендую именно туда (для других Linux OS может быть другой путь) вносить записи. Вот действующий файл для конфигурации, приведенной выше:
Первые директивы вычищают предыдущие записи и применяют указанные диапазоны. Нужно обратить внимание на следующее:
- При необходимости (для соединений типа «сеть»-«сеть») допустимо указывать через маску подсети и локальную, и удаленную сети
- Помимо режима tunnel, есть еще transport — только для соединения «хост»-«сеть» (зачем бывает нужен — не помню, но эта настройка должна совпадать на обеих сторонах. )
- Параметр unique («мутный» параметр: плохо описан в man) влияет на то, будет ли запрошена полная авторизация после обрыва(замирания) — стоит изменить это параметр при частых разрывах соединения и «невосстановления» (DISCLAMER: сказанное в этом пункте может быть наглой ложью).
Источник
Linux для чего racoon
День добрый. Решил поделиться опытом организации ВПН используя IKE(racoon).
Собственно ipsec/racoon был выбран по следующим причинам:
1) Высокая стабильность работы;
2) Кроссплатформенная реалиация (возможно объединение Linux<>Cisco; Linux<>Windows);
3) Наличие опыта организации впн используя ipsec/openswan.
Собственно статья ориентированна на unix-like пользователей. Настройка производилась на шлюзах с debian lenny на борту, ядро 2.6.30. В принципе ОС значения не имеет, на redhat-like все делается аналогично.
Реализаций ipsec существует с десяток. В моем случае рассматривается ipsec over gre. GRE был выбран в целях совместимости с cisco ipsec (хотя с ipsec на цисках дело не имел. но все когда нибудь может произойти. ).
Итак. Сначала устанавливаем необходимые пакеты:
Также добавляем в /etc/modules
Далее привожу мой конфигурационный файл /etc/network/interfaces
Хост слева (beta):
Режимы работы racoon
Racoon умеет работать в двух режимах:
1. direct
2. racoon-tool
Первый вариант рекомендуемый (пока сам не понимаю почему), но настройка через racoon-tool является несколько более простой. При настройке через racoon-tool при каждом запуске racoon генерирует файл /var/lib/racoon/racoon.conf Редактирование режима работы осуществляется путем редактирования файла /etc/default/racoon В моем случае рассматривается первый вариант.
Настройки firewall для первого хоста (beta)
Для функционирования ipsec для IKE необходимо открыть udp порт 500 (ISAKMP), а также 4500 (NAT-T). Кроме этого необходимо обеспечить беспрепятственное прохождение пакетов по протоколу esp, ah и gre между удаленными хостами:
На другом хосте сделать аналогичные действия.
Настройка /etc/ipsec-tool.conf
Пример конфига первого хоста (beta):
На втором хосте меняем ip адреса местами.
Файл /etc/racoon/psk.txt
В данном варианте рассматривается вариант с psk ключем. Однако на моем «боевом» сервере используются сертификаты X.509. Но это уже другая история.
Итак. В psk.txt в качестве ключа можно использовать произвольный текст. Я же предлагаю Вам сгенерировать ключ например таким образом:
На втором хосте делаем аналогично.
Настройка /etc/racoon/racoon.conf
Подходим к финальной фазе. Настраиваем racoon.conf. Привожу пример для первого хоста (beta).
На втором хосте меняем в конфиге ip адреса.
На этом настройка окончена. Теперь необходимо рестартануть setkey и racoon на каждом из шлюзов и поднять виртуальный интерфейс tun0:
и запускаем пинг со второго хоста на первый. tcpdump покажет наличие пакетов по протоколу esp.
На этом вроде все. если что забыл, то буду дополнять. Жду комментариев/вопросов.
Источник
IPSec Tools Racoon
IPsec-Tools это порт c FreeBSD использует утилиты setkey, racoon.
IPSec (сокращение от спецификации IP Security) — надстройка к протоколу IP, обеспечивающая безопасность протоколов более высокого уровня. IPSec был разработан для IPv6 протокола, а позже портирован на IPv4 протокол. IPSec шифрует IP-пакеты, ему безразличны интерфейсы (например gif) на шифрование которых он настроен вообще. IPSec обеспечивает IP-сжатие(IP Compression, IPcomp) пакетов перед их шифрованием. Протоколы IPsec работают на сетевом уровне (уровень 3 модели OSI). Другие защищённые протоколы, такие как Что такое SSL сертификат для сайта, почты и TLS, работают на транспортном уровне (уровни OSI 4 — 7).
ESP и AH могут быть использованы вместе или по отдельности, в зависимости от обстоятельств.
Режимы работы IPsec(транспортный, туннельный)
Существует два режима работы IPsec: транспортный режим и туннельный режим(когда в транспортном режиме работают только маршрутизаторы).
IPsec может быть использован или для непосредственного шифрования трафика между двумя хостами (транспортный режим); или для построения «виртуальных туннелей» между двумя подсетями, которые могут быть использованы для защиты соединений между двумя корпоративными сетями (туннельный режим). Туннельный режим обычно называют виртуальной частной сетью (Virtual Private Network, Что это такое VPN).
В транспортном режиме шифруется (или подписывается) только информативная часть IP-пакета. Маршрутизация не затрагивается, так как заголовок IP пакета не изменяется (не шифруется). Транспортный режим как правило используется для установления соединения между хостами. Он может также использоваться между шлюзами, для защиты туннелей, организованных каким-нибудь другим способом (IP tunnel, GRE туннели и др.).
| Транспортный режим | ||
|---|---|---|
| IP заголовок | ESP/AH заголовок | L4 payload |
В туннельном режиме IP-пакет шифруется целиком. Для того, чтобы его можно было передать по сети, он помещается в другой IP-пакет. По существу, это защищённый IP-туннель. Туннельный режим может использоваться для подключения удалённых компьютеров к виртуальной частной сети или для организации безопасной передачи данных через открытые каналы связи (например, Интернет) между шлюзами для объединения разных частей виртуальной частной сети. В туннельном режиме инкапсулируется весь исходный IP пакет, и добавляется новый IP заголовок.
| Туннельный режим | |||
|---|---|---|---|
| IP заголовок | ESP/AH заголовок | исходный IP заголовок | L4 payload |
Security Associations (SA). Для возможности проводить инкапсуляцию/декапсуляцию стороны участвующие в процессе обмена должны иметь возможность хранить секретные ключи, алгоритмы и IP адреса. Вся эта информация хранится в Ассоциациях Безопасности (SA), SA в свою очередь хранятся в Базе данных Ассоциаций Безопасности (SAD). Конфигурирование Security Association, позволяет задать например mode transport | tunnel | ro | in_trigger | beet — режим безопасной ассоциации. Соответственно, может принимать одно из значений, означающих транспортный, тоннельный, beet (Bound End-to-End Tunnel), оптимизации маршрута (route optimization) или in_trigger режимы. (последние два используются в контексте mobile ipv6).
Security Policy (SP) — политика безопасности, хранится в SPD (База данных политик безопасности). SA специфицирует, как IPsec предполагает защищать трафик, SPD в свою очередь хранит дополнительную информацию, необходимую для определения какой именно трафик защищать и когда. SPD может указать для пакета данных одно из трёх действий: отбросить пакет, не обрабатывать пакет с помощью IPSec, обработать пакет с помощью IPSec. В последнем случае SPD также указывает, какой SA необходимо использовать (если, конечно, подходящий SA уже был создан) или указывает, с какими параметрами должен быть создан новый SA. SPD является очень гибким механизмом управления, который допускает очень хорошее управление обработкой каждого пакета. Пакеты классифицируются по большому числу полей, и SPD может проверять некоторые или все поля для того, чтобы определить соответствующее действие. Это может привести к тому, что весь трафик между двумя машинами будет передаваться при помощи одного SA, либо отдельные SA будут использоваться для каждого приложения, или даже для каждого TCP соединения.
Источник
