4.5 Настройка IPSec для модели сеть-сеть
Будет реализована схема на рисунке 1.28:
 Рис 1.28 соединение сеть-сеть по протоколу IPSec
Примечание: IPSec не работает с NAT. Хотя в официальной документации сказано, что на сегодняшний день реализована возможность работы IPSec через NAT, путем включения в ядро опции:
options IPSEC_NAT_T
Это не так. Нормально данная опция работает только с оборудованием фирмы CISCO. Что к данной модели – не применимо.
Убедитесь, что в rc.conf отсутствует опция включения NAT.
4.5.1 Включение поддержки IPSec в ядре FreeBSD на серверах FreeBSD_IPSec_server и FreeBSD_IPSec_client
Поддержка IPSec есть в ядре FreeBSD, но по умолчанию она отключена. Для того чтобы её включить, необходимо перекомпилировать ядро ОС со следующими опциями:
options IPSEC – включает поддержку IPSec;
options IPSEC_NAT_T – включает поддержку работы протокола IPSec за NAT;
options IPSEC_FILTERTUNNEL - функция представлена для расширения возможности фильтровать туннелируемые пакеты;
options IPSEC_DEBUG – включает отладочный режим, для подробного отчета в логах;
device crypto – включение поддержки gif интерфейса, через который будет идти зашифрованный трафик.
Для этого создадим свой файл конфигурации ядра в каталоге kernels в домашней директории пользователя server, скопировав его из системного каталога /usr/src/sys/i386/conf/:
mkdir /home/server/kernels
cp /usr/src/sys/i386/conf/GENERIC /home/server/kernels/server
cd /usr/src/sys/i386/conf
ln –s /home/server/kernels/server
Теперь, необходимо открыть его и добавить опции ядра:
nano server
options IPSEC
options IPSEC_NAT_T
options IPSEC_FILTERTUNNEL
options IPSEC_DEBUG
device crypto
Теперь, переходим в каталог /usr/src и даем команду на сборку, установку ядра и последующую перезагрузку.
make buildkernel KERNCONF=server
make installkernel KERNCONF=server
reboot
После того, как сервера перезагрузятся, необходимо настроить gif интерфейс для создания туннеля, через который будет идти зашифрованный трафик.
4.5.2 Настройка виртуального интерфейса gif
Для настройки gif интерфейсов, необходимо на обоих серверах открыть файл /etc/rc.conf и добавить в него строки:
gif_interfaces=”gif1” # на клиенте – gif0
gifconfig_gif1=192.168.5.23 192.168.5.21 # настраиваем интерфейс на #соединение по реальным IP-адресам.
# на клиенте эта строчка примет вид gifconfig_gif1=192.168.5.21 192.168.5.23
static_routes=”vpn” # заводим статический маршрут под именем vpn
route_vpn=”192.168.55.0/24 –interface gif1” # любой пакет адресованный в #сеть 192.168.55.0/24 будет принудительно проходить через gif-интерфейс.
#на клиенте это выглядело бы так: route_vpn=”192.168.44.0/24 –interface gif0”
export route_vpn # загрузить статический маршрут при каждом запуске сервера.
После добавления этих строк в конфигурационные файлы серверов FreeBSD_IPSec_server и FreeBSD_IPSec_client, необходимо перезагрузить сервера и ввести команду ifconfig gif1 на сервере и ifconfig gif0 на клиенте. Результаты этих команд показаны на рисунке 1.29.
 Рис 1.29 результат команды ifconfig gif 1 и ifconfig gif0
Далее, необходимо проверить, работает ли туннель. Если с сервера FreeBSD_IPSec_server делать ping до сервера FreeBSD_IPSec_client, то пакеты должны идти. Рисунок 1.30 демонстрирует это:
 Рис 1.30 Обмен пакетами между FreeBSD_IPSec_server и FreeBSD_IPSec_client
После того, как туннель заработал, можно перейти непосредственно к настройке IPSec. Для настройки параметров безопасности (security associations) есть два варианта. Можно настроить их вручную для обоих серверов, задав алгоритм шифрования, ключи для шифрования и так далее, или использовать демоны, реализующие Internet Key Exchange protocol (IKE), который сделает это за нас.
Рекомендуется второе. Помимо прочего, этот способ более прост.
Редактирование и отображение политики безопасности выполняется с помощью setkey. По аналогии, setkey используется для настройки таблиц политики безопасности ядра так же, как route используется для настройки таблиц маршрутизации ядра. Setkey также может отображать текущие параметры безопасности, и продолжая аналогию дальше, это соответствует netstat –r.
Существует множество демонов для управления параметрами безопасности в FreeBSD. Здесь будет описано использование одного из них, racoon — он доступен в составе порта ipsec-tools.
4.5.3 Настройка демона racoon
Даемон racoon должен работать на обоих серверах. На каждом из серверов он настраивается с IP адресом другого конца VPN, и секретным ключом (должен быть одним и тем же на обоих серверах).
Эти два демона подключаются друг к другу, подтверждают, что они именно те, за кого себя выдают (используя секретный ключ, заданный нами). Затем демоны генерируют новый секретный ключ и используют его для шифрования трафика через VPN. Они периодически изменяют этот ключ, так что даже если атакующий сломает один из ключей (что теоретически почти невозможно) это не даст ему слишком много — он сломал ключ, который два демона уже сменили на другой.
Настройки racoon сохраняются в файле /usr/local/etc/racoon/racoon.conf. Другим компонентом настройки racoon, который потребуется изменить, является «предварительный ключ», который racoon ищет в файле /usr/local/etc/raccoon/raccoon.conf.
Необходимо отметить, что предварительный ключ не используется для шифрования трафика через VPN соединение. Это просто маркер, позволяющий управляющим ключами и двум демонам доверять друг другу.
Psk.txt содержит строку для каждого удаленного сервера, с которым происходит соединение. В нашем примере два сервера. Каждый файл psk.txt будет содержать одну строку (каждый конец VPN общается только с другим концом).
На сервере FreeBSD_IPSec_server эта строка будет выглядеть так:
192.168.5.21 hello
То есть публичный IP-адрес противоположной стороны, пробел и текстовая строка c секретной фразой.
На сервере FreeBSD_IPSec_client эта строка будет выглядеть так:
192.168.5.23 hello
То есть публичный IP адрес удаленной стороны и та же секретная фраза.
Теперь отредактируем на обоих серверах файл racoon.conf до следующего вида:
path pre_shared_key "/usr/local/etc/racoon/psk.txt";
log info;
padding {
maximum_length 20;
randomize off;
strict_check off;
exclusive_tail off;
}
listen {
isakmp 192.168.5.23; # на клиенте будет 192.168.5.21
strict_address;
# adminsock "/var/db/racoon/racoon.sock";
}
timer {
counter 5;
interval 20 sec;
persend 1;
phase1 30 sec;
phase2 15 sec;
}
remote 192.168.5.21 { # на клиенте будет 192.168.5.23
exchange_mode aggressive,main;
lifetime time 24 hour;
my_identifier address;
peers_identifier address;
passive off;
generate_policy off;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2;
}
}
sainfo anonymous {
encryption_algorithm 3des;
authentication_algorithm hmac_md5, hmac_sha1;
lifetime time 1 hour ;
compression_algorithm deflate;
}
После изменения конфигурационного файла, необходимо добавить правила политик безопасности для трафика, который мы будем шифровать. Например, для трафика идущего от сервера FreeBSD_IPSec_server это правило будет эквивалентно словам:
Если пакет отправляется с 192.168.5.23, и предназначен для 192.168.5.21, расшифровать его, используя необходимые параметры безопасности.
Если пакет отправляется с 192.168.5.21, и предназначен для 192.168.5.23, расшифровать его, используя необходимые параметры безопасности.
Для сервера FreeBSD_IPSec_client будет то же самое, но наоборот (в обратную сторону).
Теперь, нам необходимо создать эти правила на обоих серверах. На сервере FreeBSD_IPSec_server отредактируем файл /usr/local/etc/ipsec.conf до следующего содержания:
flush;
spdflush;
spdadd 192.168.44.0/24 192.168.55.0/24 any -P out ipsec esp/tunnel/192.168.5.23-192.168.5.21/require;
spdadd 192.168.55.0/24 192.168.44.0/24 any -P in ipsec esp/tunnel/192.168.5.21-192.168.5.23/require;
На сервере FreeBSD_IPSec_client этот файл будет иметь обратный вид:
flush;
spdflush;
spdadd 192.168.55.0/24 192.168.44.0/24 any -P out ipsec esp/tunnel/192.168.5.21-192.168.5.23/require;
spdadd 192.168.44.0/24 192.168.55.0/24 any -P in ipsec esp/tunnel/192.168.5.23-192.168.5.21/require;
После этого необходимо запустить racoon и IPSec на обоих серверах. Это делается добавлением в rc.conf следующих строк:
ipsec_enable="YES"
ipsec_file="/usr/local/etc/ipsec.conf"
racoon_enable="YES"
racoon_create_dirs="YES"
Сохраняем изменения, перезагружаем сервера.
После перезагрузки, необходимо убедиться в том, что туннель работает правильно. Для этого, на сервере FreeBSD_IPSec_server запустим tcpdump на интерфейсе gif1, а с сервера FreeBSD_IPSec_client будет командой ping обмениваться пакетами с FreeBSD_IPSec_server (рис. 1.31).
 Рис. 1.31 Результат ping и tcpdump
Еще немного теории.
Существует 2 базы. SAD и SPD. С обеими работа осуществляется через утилиту setkey.
SA [setkey -D] - связь (ассоциация) безопасности. Это термин IPSec для обозначения соединения. При установленном соединении для каждого используемого протокола создается пара SA. Пара, т.к. SA - это однонаправленное соединение, а данные передаются в обоих направлениях. SA- пары хранятся на каждом узле. Если есть SA - соединение установлено.
SPD [setkey -DP] - база политик безопасности. Политики безопасности указывают, какой именно трафик надо шифровать. И какой трафик приходит шифрованным. Если на одном сервере укажем, например, что исходящий трафик на порту 1701 надо шифровать, а на соседе не указываем, что на порт 1701 приходит шифрованный трафик, то ничего работать не будет.
Данная база может заполняться из setkey.conf путем setkey -f setkey.conf. Но в конфигурационном файле raccoon.conf есть интересная опция generate_policy on;. Если на Сервере FreeBSD_IPSec_server ее поставить в on, то на сервере будут создаваться политики, соответствующие политикам на клиенте. Например, если на клиенте FreeBSD_IPSec_client мы укажем, что исходящий трафик на порт 1701 необходимо шифровать, то на сервере автоматически создастся правило, что входящий трафик с данного клиента на порт 1701 будет шифрованным. Для начала рекомендую поставить on и оставить политики на сервере пустыми. Они заполнятся в соответствии с клиентом. На клиенте же необходимо заполнять вручную. Если взаимодействие политик будет настроено неправильно, шифрование не заработает и SA не создастся.
Реультат команды setkey –D сервера FreeBSD_IPSec_server показан на рисунке 1.32:
 Рис. 1.32 setkey –D на сервере FreeBSD_IPSec_server
Реультат команды setkey –DP сервера FreeBSD_IPSec_server показан на рисунке 1.33:
 Рис 1.33 setkey –DP на сервере FreeBSD_IPSec_server
Видно, что ассоциации и политики шифрования трафика созданы. |
