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 <ip_gateway_of_the_2th_side> - явная попытка подключиться. Замечу, что при правильной настройке такое подключение осуществляется неявно при любом запросе удаленной стороны (ping, ssh и т.п.). Команды малополезны: об ошибках они НЕ сообщают. Удобны, чтобы сразу после их выполнения смотреть все ошибки в /var/log/messages.
- setkey -DP - показывает "шаблоны" соединений (должны быть нетривиальные записи даже до установленного соединения).
- setkey -DH (полный аналог: racoonctl show-sa ipsec) - показывает установленные соединения (обычно парами: из А в В, из В в А) с некоторой статистикой. Замечены дублирующиеся записи (порты, например, могут быть разные), но это не влияло на работоспособность.
- racoonctl show-sa isakmp - показывает сохраненные куки для соединений (результат фазы 1)
Настройка racoon
Основной файл настроек /etc/racoon.conf:
path include "/etc/racoon"; path pre_shared_key "/etc/racoon/psk.txt"; path certificate "/etc/racoon/certs"; path script "/etc/racoon/scripts"; listen { adminsock "/var/lib/racoon/racoon.sock" "root" "wheel" 0600; } remote 80.254.27.106 { exchange_mode main; proposal_check obey; proposal { encryption_algorithm des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group modp768; } nat_traversal on; } sainfo address 91.232.225.223/32 any address 192.168.3.0/24 any { lifetime time 18000 seconds; encryption_algorithm des; authentication_algorithm hmac_sha1; compression_algorithm deflate; pfs_group modp768; } sainfo address 192.168.3.0/24 any address 91.232.225.223/32 any { lifetime time 18000 seconds; encryption_algorithm des; authentication_algorithm hmac_sha1; compression_algorithm deflate; pfs_group modp768; } remote anonymous { exchange_mode aggressive; generate_policy on; proposal_check obey; proposal { encryption_algorithm des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group modp1024; } nat_traversal on; verify_identifier off; } sainfo anonymous { lifetime time 90000 seconds; encryption_algorithm des; authentication_algorithm hmac_sha1; compression_algorithm deflate; pfs_group modp1024; }
Выше приведен действующий ныне файл настройки racoon'a (показаны настройки соединения только с одним хостом и "всеми остальными"). Кратко о параметрах:
- path pre_shared_key: здесь хранятся пароли для соединения с хостами. Сам файл должен иметь разрешение 600 (владелец root:root). Указанные ip проверяются по очереди сверху вниз, поэтому запись "для всех остальных" нужно помещать внизу списка. Полагаю ip вида 123.123.123.0/24 тоже принимаются. Отметим сразу, что ключевым ip здесь выступает именно внешний ip удаленного сервера, а не внутренние. Формат записей:
80.254.27.106 Password123 * Pass456
- remote <ip> (или anonymous для всех): блок настроек относящихся к соединению с определенным хостом (или всеми) независимо от того, какая сторона инициировала соединение.
- exchange_mode: main или aggressive (можно указать оба через запятую). Второй используется при соединениях с серыми оконечными ip, делая меньше запросов. Есть подозрение, что именно в этом режиме возникает вышеуказанная проблема с "недостертыми" cookies. По возможности рекомендуется применять Main.
- proposal_check: уже не помню...
- proposal { }: блок допустимых параметров криптования, обе стороны должны договориться, какое шифрование использовать. Допустимые можно перечислять через запятую. Главное, чтобы по всем четырем параметрам нашлись совпадающие. В РФ запрещено применение более стойких алгоритмов, чем des (3des, aes и т.д.), поэтому в официальных роутерах Zyxel доступен только des... (Во всякой китайщине, в т.ч. TPLink можно выбирать все, что душе угодно). Еще приведу синонимы для параметра длины ключа
Zyxel | Racoon | Комментарий |
DH1 | modp768 | Считается небезопасным - не рекомендован к применению, в StrongSWAN поэтому поддержки нет |
DH2 | modp1024 | |
DH5 | modp15?? | Чем длиннее, тем медленнее обработка пакетов - упоминалось значительное снижение скорости обработки пакетов |
- authentication_method: будем авторизовываться по фразе из psk.txt
- nat_traversal: on или off - проверка, за NAT'ом ли конечная цель. Отключать нужно только в случае возникновения проблем.
- sainfo Блоки, на основании которых генерируются правила маршрутизации... Хм... Не заметил, чтобы их указания было достаточно без дополнительных команд через setkey. И наличие их необходимо. Так что нужно писать два блока "туды-сюды" (да, с повторением параметров шифрования, без этого - не работало... Подозреваю, что эти записи используются на второй фазе, а предыдущие - на первой), за исключением последнего для всех: там достаточно одной записи.
- lifetime time: (именно с пробелом, а не подчеркиванием) время действия cookies - важный параметр, тоже должен совпадать на обеих сторонах.
Использование setkey
Вышеуказанных настроек достаточно, чтобы проводить первую фазу соединения, но недостаточно, чтобы получить фактический обмен пакетами по этому протоколу, поэтому нужно применить настройки, указанные в файле через команду (от root'а):
setkey -f <путь_к_файлу>
При (пере)запуске службы racoon, автоматом считываются настройки из /etc/racoon/setkey.conf (это можно увидеть в скрипте /etc/init.d/racoon), поэтому рекомендую именно туда (для других Linux OS может быть другой путь) вносить записи. Вот действующий файл для конфигурации, приведенной выше:
#!/usr/sbin/setkey -f flush; spdflush; spdadd 91.232.225.223/32 192.168.3.0/24 any -P out ipsec esp/tunnel/91.232.225.223-80.254.27.106/unique; spdadd 192.168.3.0/24 91.232.225.223/32 any -P in ipsec esp/tunnel/80.254.27.106-91.232.225.223/unique; spdadd 91.232.225.223/32 192.168.1.0/24 any -P out ipsec esp/tunnel/91.232.225.223-0.0.0.0/unique; spdadd 192.168.1.0/24 91.232.225.223/32 any -P in ipsec esp/tunnel/0.0.0.0-91.232.225.223/unique;
Первые директивы вычищают предыдущие записи и применяют указанные диапазоны. Нужно обратить внимание на следующее:
- При необходимости (для соединений типа "сеть"-"сеть") допустимо указывать через маску подсети и локальную, и удаленную сети
- Помимо режима tunnel, есть еще transport - только для соединения "хост"-"сеть" (зачем бывает нужен - не помню, но эта настройка должна совпадать на обеих сторонах...)
- Параметр unique ("мутный" параметр: плохо описан в man) влияет на то, будет ли запрошена полная авторизация после обрыва(замирания) - стоит изменить это параметр при частых разрывах соединения и "невосстановления" (DISCLAMER: сказанное в этом пункте может быть наглой ложью).