Racoon: различия между версиями
м (13 версий) |
|||
(не показано 11 промежуточных версий 1 участника) | |||
Строка 1: | Строка 1: | ||
=== Racoon (VPN) сервер === | === Racoon (VPN IPSec) сервер === | ||
Racoon позволяет осуществлять VPN-соединения типа "транспорт" или "туннель" между компьютерами и целыми подсетями. Представляет собой собственно сервис для осуществления первой фазы соединения и задания правил фазы 2. Основных утилит по работе с VPN-соединением две: racoonctl и setkey, функционал которых несколько пересекается. | Racoon позволяет осуществлять VPN-соединения типа "транспорт" или "туннель" между компьютерами и целыми подсетями. Представляет собой собственно сервис для осуществления первой фазы соединения и задания правил фазы 2. Основных утилит по работе с VPN-соединением две: racoonctl и setkey, функционал которых несколько пересекается. Команда racoon - собственно демон - ожидает подключений или осуществляет подключение сам. После обмена данными по выбору шифрования и подтверждения ключевой фразы (пароль) создает cookie соединения, который используется при переподключении в "времени жизни" этого самого cookie. Далее в ход вступают правила, настроенные через setkey - это фактически инструкции для изменения маршрутов. Приведем несколько полезных команд... | ||
=== (Бес)Полезные команды === | === (Бес)Полезные команды === | ||
*/etc/init.d/racoon start|stop|restart|status - позволяет управлять службой, но делать это стоит крайне осторожно, дело в том, что рестарт этой службы обрубит соединения и вычистит куки, сохраненные после фазы 1. Может так получиться, что вторая сторона будет продолжать их требовать при попытке снова подключиться (вместо полноценной процедуры обмена сертификатами и пр.), что помешает восстановить соединение, пока, например, второй сервер не будет перезапущен тоже... | *'''/etc/init.d/racoon start|stop|restart|status''' - позволяет управлять службой, но делать это стоит крайне осторожно, дело в том, что рестарт этой службы обрубит соединения и вычистит куки, сохраненные после фазы 1. Может так получиться, что вторая сторона будет продолжать их использовать (и, следовательно, требовать) при попытке снова подключиться (вместо полноценной процедуры обмена сертификатами и пр.), что помешает восстановить соединение, пока, например, второй сервер не будет перезапущен тоже... Кстати, информативность сообщений о такой ошибке будет... никакой. | ||
*racoonctl reload-config - без разрыва имеющихся соединений позволяет применить новые настройки - | *'''racoonctl reload-config''' - без разрыва имеющихся соединений позволяет применить новые настройки - рекомендуется использовать вместо рестарта службы, чтобы перечитать настройки. | ||
*racoonctl vpn-connect|vpn-disconnect <ip_gateway_of_the_2th_side> - явная попытка подключиться. Замечу, что при правильной настройке такое подключение осуществляется неявно при любом запросе удаленной стороны (ping, ssh и т.п.). Команды малополезны: об ошибках они НЕ сообщают. | *'''racoonctl vpn-connect|vpn-disconnect <ip_gateway_of_the_2th_side> '''- явная попытка подключиться. Замечу, что при правильной настройке такое подключение осуществляется неявно при любом запросе удаленной стороны (ping, ssh и т.п.). Команды малополезны: об ошибках они НЕ сообщают. Удобны, чтобы сразу после их выполнения смотреть все ошибки в /var/log/messages. | ||
*setkey -DP | *'''setkey -DP ''' - показывает "шаблоны" соединений (должны быть нетривиальные записи даже до установленного соединения). | ||
*setkey -DH (полный аналог: racoonctl show-sa ipsec) - показывает установленные соединения (обычно парами: из А в В, из В в А) с некоторой статистикой | *'''setkey -DH '''(полный аналог: '''racoonctl show-sa ipsec''') - показывает установленные соединения (обычно парами: из А в В, из В в А) с некоторой статистикой. Замечены дублирующиеся записи (порты, например, могут быть разные), но это не влияло на работоспособность. | ||
*racoonctl show-sa isakmp - показывает сохраненные куки для соединений (результат фазы 1) | *'''racoonctl show-sa isakmp''' - показывает сохраненные куки для соединений (результат фазы 1) | ||
=== Требования к ядру === | |||
При использовании OpenVZ выяснилось, что на хостовой машине потребовалась загрузка дополнительных модулей, а именно: | |||
*af_key | |||
*xfrm4_tunnel | |||
*authenc | |||
*xfrm4_mode_tunnel | |||
*esp4 | |||
Возможно, не все они обязательны, но зато наверняка. | |||
=== Настройка racoon === | |||
Основной файл настроек /etc/racoon.conf: | |||
<pre> | |||
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; | |||
} | |||
</pre> | |||
Выше приведен действующий ныне файл настройки racoon'a (показаны настройки соединения только с одним хостом и "всеми остальными"). Кратко о параметрах: | |||
*'''path pre_shared_key''': здесь хранятся пароли для соединения с хостами. Сам файл должен иметь разрешение 600 (владелец root:root). Указанные ip проверяются по очереди сверху вниз, поэтому запись "для всех остальных" нужно помещать внизу списка. Полагаю ip вида 123.123.123.0/24 тоже принимаются. Отметим сразу, что ключевым ip здесь выступает именно '''''внешний ip''''' удаленного сервера, а не внутренние. Формат записей: | |||
80.254.27.106 Password123 | |||
* Pass456 | |||
*'''listen { }''': способ "идентификации" демона (их может быть несколько), нужен для явного способа управления через racoonctl. Оказалось, что при компиляции racoon'а требуется включение опции --enable-adminport=yes | |||
*'''remote <ip>''' (или '''anonymous''' для всех): блок настроек относящихся к соединению с определенным хостом (или всеми) независимо от того, какая сторона инициировала соединение. | |||
*'''exchange_mode''': main или aggressive (можно указать оба через запятую). Второй используется при соединениях с серыми оконечными ip, делая меньше запросов. Есть подозрение, что именно в этом режиме возникает вышеуказанная проблема с "недостертыми" cookies. По возможности рекомендуется применять Main. | |||
*'''proposal_check''': принимать ли "пропозалы", если их времена жизни не совпадают, возможно, exact - наилучший вариант. | |||
*'''proposal { }''': блок допустимых параметров криптования, обе стороны должны договориться, какое шифрование использовать. Допустимые можно перечислять через запятую. Главное, чтобы по всем четырем параметрам нашлись совпадающие. В РФ запрещено применение более стойких алгоритмов, чем des (3des, aes и т.д.), поэтому в официальных роутерах Zyxel доступен только des... (Во всякой китайщине, в т.ч. TPLink можно выбирать все, что душе угодно). Еще приведу синонимы для параметра длины ключа | |||
{| border="1" | |||
|- | |||
|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'а): | |||
setkey -f <путь_к_файлу> | |||
При (пере)запуске службы racoon, автоматом считываются настройки из /etc/racoon/setkey.conf (это можно увидеть в скрипте /etc/init.d/racoon), поэтому рекомендую именно туда (для других Linux OS может быть другой путь) вносить записи. Вот действующий файл для конфигурации, приведенной выше: | |||
<pre> | |||
#!/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; | |||
</pre> | |||
Первые директивы вычищают предыдущие записи и применяют указанные диапазоны. Нужно обратить внимание на следующее: | |||
*При необходимости (для соединений типа "сеть"-"сеть") допустимо указывать через маску подсети и локальную, и удаленную сети | |||
*Помимо режима tunnel, есть еще transport - только для соединения "хост"-"сеть" (зачем бывает нужен - не помню, но эта настройка должна совпадать на обеих сторонах...) | |||
*Параметр unique ("мутный" параметр: плохо описан в man) влияет на то, будет ли запрошена полная авторизация после обрыва(замирания) - стоит изменить это параметр при частых разрывах соединения и "невосстановления" (DISCLAMER: сказанное в этом пункте может быть наглой ложью). |
Текущая версия на 01:54, 11 октября 2016
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)
Требования к ядру
При использовании OpenVZ выяснилось, что на хостовой машине потребовалась загрузка дополнительных модулей, а именно:
- af_key
- xfrm4_tunnel
- authenc
- xfrm4_mode_tunnel
- esp4
Возможно, не все они обязательны, но зато наверняка.
Настройка 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
- listen { }: способ "идентификации" демона (их может быть несколько), нужен для явного способа управления через racoonctl. Оказалось, что при компиляции racoon'а требуется включение опции --enable-adminport=yes
- remote <ip> (или 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'а):
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: сказанное в этом пункте может быть наглой ложью).