Не вдаваясь в детали, скажу что в центральном офисе установлен сервер под управлением Debian Squeeze, с которым и нужно было объединить MikroTik туннелем IPSec. На самом деле офис этот тоже не совсем центральный и имеется большой набор ресурсов, который доступен через каналы в вышестоящие локальные сети. Список используемых удалённым офисом ресурсов непостоянен, а потому стандартная настройка IPSec с шифрованием трафика между заранее известными сетями нам не подойдёт. В данном случае нужно считать, что за центральным офисом как бы находится сеть 0.0.0.0/0. В удалённом же офисе используется сеть 192.168.81.240/28.
Если изобразить это схематично, то получится такая схема:
[0.0.0.0/0] --- 192.168.81.1 debian 11.11.11.11 ==== 22.22.22.22 mikrotik 192.168.81.241 --- [192.168.81.240/28]1. Хождение по мукам
Этот раздел можно безболезненно пропустить. Здесь я просто дал волю своей графомании и описал, какой ценой мне достался этот рецепт. Можете считать меня неудачником :)
Как ни странно, но сходу настроить даже тестовую конфигурацию мне не удалось. Туннель упорно не хотел подниматься и трафик не шёл. Стало понятно, что взять эту задачу нахрапом не получится. Маршрутизатор отдали мне на растерзание домой. Дома у меня есть коммутатор с поддержкой VLAN и компьютер, на котором я думал настроить необходимое количество виртуальных машин и соединить всё это между собой, собрав этакий виртуальный стенд.
В первый выходной я потратил на всё это безобразие около 9 часов и всё-таки поднял туннель, соединив внешний интерфейс маршрутизатора с внешним интерфейсом виртуальной машины под управлением Debian:
debian 11.11.11.11 === 11.11.11.12 mikrotikЯ, правда, так и не понял, чем настроенная конфигурация отличалась от той, которую я пытался настраивать первоначально. И так много времени ушло в этот раз скорее не на саму настройку, а на подготовительные работы - проброс VLAN, поиск нормально работающей системы для запуска виртуальных машин (воспользовался VirtualBox), её правильную настройку (нужно было собрать дополнительные модули для ядра Linux), скачивание и установку в виртуальную машину Debian Squeeze. Дополнительное время ушло на тупление с мостовым интерфейсом, который я настроить-настроил, а поднять забыл.
Ещё некоторое время было потрачено из-за моей невнимательности, когда IPSec стал требовать вдруг шифрования трафика и на локальном интерфейсе, в результате чего я потерял управление и мне пришлось сбрасывать MikroTik и настраивать его снова. Зато я узнал о существовании "безопасного режима" в RouterOS.
Наконец, после установки первоначального туннеля я потратил ещё некоторое время на шлифование конфигурации.
Во второй выходной я уже попытался воссоздать будущие условия работы маршрутизатора более точно. Сначала настроил такую схему, с дополнительной виртуалкой, которая изображала сеть провайдера и маршрутизировала трафик между Debian и MikroTik'ом:
debian 11.11.11.11 ==(провайдер)== 22.22.22.22 mikrotikДалее я настроил ещё две виртуальные машины, каждая из которых изображала компьютер в офисе. Одна виртуальная машина изображала компьютер в центральном офисе, а вторая - в удалённом офисе. Получилась уже такая схема:
[192.168.80.113/24] --- 192.168.81.1 debian 11.11.11.11 ==(провайдер)== 22.22.22.22 mikrotik 192.168.81.241 --- [192.168.81.242/28]Далее я потратил ещё некоторое время на тестирование настроек при включенном NAT на Debian. Дело в том, что NAT изменяет адрес отправителя (что ожидаемо - для этого он и предназначен). Из-за этого пакет с изменившимися IP-адресами отправителя и получателя может не попасть под правила IPSec и уйти не в удалённый офис через туннель IPSec, а уйти прямо в сеть провайдера безо всякого шифрования. Этот момент тоже нужно учитывать, чем я и занялся.
В результате получилась отлаженная конфигурация. Я настроил реальный сервер Debian и передал настроенный маршрутизатор своим бывшим коллегам. Были, правда, некоторые сомнения в том, что я всё учёл. Но, как это ни странно, когда маршрутизатор установили на место, всё сразу заработало как нужно. Полученный рецепт привожу ниже.
2. Настройка Debian
Для настройки туннеля я выбрал алгоритм шифрования blowfish, алгоритм хэширования sha1 и группу Дифи-Хеллмана, исходя из желания достичь наибольшей защищённости, поддерживаемой программным обеспечением с обеих сторон туннеля.
Перед настройкой укажу на особенность настраиваемого IPSec-туннеля. У этого туннеля нет IP-адресов конечных точек внутри туннеля. Фактически, IPSec хватает пакеты перед выходом из сетевого интерфейса, выполняет шифрование пакета и кладёт в IP-пакет, в котором указаны "белые" IP-адреса обеих сторон туннеля. Чтобы этот процесс не зациклился и пакеты не продолжали шифроваться и вкладываться снова и снова, IPSec'у чётко указываются правила, пакеты с какими IP-адресами необходимо подвергать обработке. Из-за такой особенности кажется весьма необычным, что пакеты с локальными IP-адресами маршрутизируются прямо через провайдерскую сеть. Очень важно понимать эту особенность, т.к. в противном случае при настройке IPSec можно натурально сойти с ума :)
Устанавливаем необходимые пакеты:
# apt-get install ipsec-tools racoonПрописываем настройки racoon в файле /etc/racoon/racoon.conf:
remote 22.22.22.22 { nat_traversal off; exchange_mode main; proposal { encryption_algorithm blowfish; hash_algorithm sha1; authentication_method pre_shared_key; dh_group modp6144; } } sainfo anonymous { pfs_group modp6144; lifetime time 1 hour; encryption_algorithm blowfish; authentication_algorithm hmac_sha1; compression_algorithm deflate; }При помощи утилиты pwgen из одноимённого пакета генерируем случайный будущий общий ключ:
$ pwgen 32Помещаем ключ в файл /etc/racoon/psk.txt:
22.22.22.22 generated_psk_sequenceНастроим ipsec, отредактировав файл /etc/ipsec-tools.conf
flush; spdflush; spdadd 192.168.81.240/28 192.168.81.240/28 any -P out none; spdadd 0.0.0.0/0 192.168.81.240/28 any -P out ipsec esp/tunnel/11.11.11.11-22.22.22.22/require; spdadd 192.168.81.240/28 192.168.81.240/28 any -P in none; spdadd 192.168.81.240/28 0.0.0.0/0 any -P in ipsec esp/tunnel/22.22.22.22-11.11.11.11/require;Запустим настроенные демоны:
# /etc/init.d/setkey start # /etc/init.d/racoon startДобавляем маршруты в удалённую локальную сеть через внешний интерфейс:
# ip route add to 192.168.81.240/28 via 11.11.11.11 src 11.11.11.11Добавляем правила в пакетный фильтр для прохождения трафика IPSec:
# iptables -A INPUT -i eth0 -m udp -p udp -s 22.22.22.22 --dport 500 -j ACCEPT # iptables -A INPUT -i eth0 -p ah -s 22.22.22.22 -j ACCEPT # iptables -A INPUT -i eth0 -p esp -s 22.22.22.22 -j ACCEPTДобавляем правила в пакетный фильтр для трафика из сети удалённого офиса к серверу Debian:
# iptables -A INPUT -i eth0 -s 192.168.81.240/28 -p tcp -m multiport --dport 25,53,80,110,143,3128 -j ACCEPT # iptables -A INPUT -i eth0 -s 192.168.81.240/28 -p udp -m udp --dport 53 -j ACCEPTЕсли на внешнем интерфейсе осуществляется трансляция адресов, то сеть, доступную через туннель IPSec, нужно исключить из обработки. Ниже приведены два правила - первое исключает сеть из обработки, второе осуществляет трансляцию адресов остального трафика:
# iptables -t nat -I POSTROUTING -o eth0 -d 192.168.81.240/28 -j ACCEPT # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 11.11.11.113. Настройка MikroTik
Внимание! Указанные ниже команды приведены для примера. Будьте внимательны и не копируйте их прямо в командную строку. Прежде чем выполнять любые примеры команд remove для начала проверьте при помощи команды print, что вы собрались удалить. Внимательно проверяйте IP-адреса и вообще - делайте что-то только если вы чётко представляете, зачем вы это делаете.
Добавляем новый адрес на локальном интерфейсе:
/ip address add interface=ether2-master-local address=192.168.81.241/28Удаляем старый адрес 192.168.88.1, который был настроен на мостовом интерфейсе в конфигурации по умолчанию:
/ip address remove numbers=0Переподключаемся на новый адрес, удаляем мостовой интерфейс:
/interface bridge remove numbers=0Удаляем настройки DHCP-клиента на внешнем интерфейсе:
/ip dhcp-client remove numbers=0Настраиваем новый внешний адрес:
/ip address add interface=ether1-gateway address=22.22.22.22/25Настраиваем маршрут по умолчанию:
/ip route add gateway=22.22.22.1Удаляем настройки NAT:
/ip firewal nat remove numbers=0Удаляем правила пакетного фильтра:
/ip firewall filter remove numbers=0,1,2,3,4,5Отключаем доступ к устройству по всем протоколам, кроме ssh:
/ip service disable numbers=0,1,2,5,6,7Отключаем MAC-telnet (телнет с подключением по MAC-адресу, а не по IP-адресу):
/tool mac-server disable numbers=1,2,3,4,5,6Теперь переходим к собственно настройке IPSec.
Настраиваем предпочитаемые алгоритмы аутентификации, шифрования и обмена ключами:
/ip ipsec proposal set default auth-algorithms=sha1 \ enc-algorithms=blowfish \ lifetime=1h \ pfs-group=modp6144Настраиваем политику, какой трафик шифровать:
/ip ipsec policy add src-address=192.168.81.240/28 dst-address=192.168.81.240/28 \ sa-src-address=22.22.22.22 sa-dst-address=11.11.11.11 \ tunnel=no action=none add src-address=192.168.81.240/28 dst-address=0.0.0.0/0 \ sa-src-address=22.22.22.22 sa-dst-address=11.11.11.11 \ tunnel=yes action=encrypt proposal=defaultНастраиваем, с кем нужно установить соединение IPSec:
/ip ipsec peer add address=11.11.11.11/32 local-address=22.22.22.22 port=500 \ auth-method=pre-shared-key secret="generated_psk_sequence" dh-group=modp6144 \ enc-algorithm=blowfish hash-algorithm=sha1 \ lifetime=1h nat-traversal=no4. Использованные материалы
8 комментариев:
Racoon на линуксе какой-то очень нестабильный.
OpenSwan проще и легче)
Настраивал соединения FreeBSD - Cisco, Debian - Mikrotik и никакой нестабильности не замечал - всё прекрасно работает.
Если OpenSwan проще и легче - напишите об этом статью и расскажите, что не понравилось в Racoon.
Не так сформулировал в предыдущем комментарии
Здравствуйте, есть подобная проблема связать FreeBSD c Mikrotik используя тот же ipsec-tools c racoon. Не могли бы вы сказать какие изменения потребуются в вашей схеме (политики шифрования, настройки, firewall и т.д.) если будет схема с двумя фиксированными сетями и двумя роутерами FreeBSD 11.11.11.11 и Mikrotik 22.22.22.22 как на схеме ниже:
[192.168.0.0/24] --- 192.168.0.1 freebsd 11.11.11.11 ==== 22.22.22.22 mikrotik 192.168.1.1 --- [192.168.1.0/24]
если по вашей схеме смотреть немного не понятна левая сторона - 192.168.81.1 не попадает в диапазон указанной вами сети [192.168.80.113/24]
[192.168.80.113/24] --- 192.168.81.1 debian 11.11.11.11 ==(провайдер)== 22.22.22.22 mikrotik 192.168.81.241 --- [192.168.81.242/28]
пожалуйста можно ли для исключения путаницы свести изменения при переходе к простому виду:
[192.168.0.0/24] --- 192.168.0.1 debian(freebsd)(ipsec-tools,racoon) 11.11.11.11 ==(провайдер)== 22.22.22.22 mikrotik 192.168.1.1 --- [192.168.1.0/24]
Скажите когда в микротике вы делаете настройки /ip address add interface=ether2-master-local address=192.168.81.241/28 у вас порт ether2-master-local становится независимым портом с адресом 192.168.81.241/28 или он остается в составе бриджа куда входят порты 2-5 и вы назначаете адрес 192.168.81.241/28 всему бриджу из портов 2-5?Желательно было привести полную конфигурацию касающуюся данной настройки конфигурацию интерфейсов, настройки ipsec, таблицы маршрутизации с обоих сторон.
Какие изменения потребуются - сказать не могу. Возможно потребуется поменять используемые алгоритмы шифрования, аутентификации и т.п., т.к. каждая из сторон может поддерживать определённое их подмножество.
В вопросе нет специфики. Попробуйте настроить, тогда у вас либо всё заработает, либо появятся какие-то сообщения об ошибках, на которые можно будет ориентироваться для уточнения настроек.
andy, почти в каждой из статей в интернете про настройку IPSec защищают трафик между двумя непересекающимися подсетями в двух разных офисах. Настройка IPSec такого рода тривиальна и не позволяет защищать весь трафик, проходящий между офисами.
В моей практике мне встречались только случаи, когда один из офисов был головным и составить список всех сетей в нём не представлялось возможным. Поэтому мне всегда требовалось выполнять защиту трафика между сетью удалённого офиса и неопределённым списком сетей, находящихся как в головном офисе, так и за его пределами.
В интернете не было статей, в которых бы описывался мой случай. Я не стал бы писать ещё одну статью про настройку идеального сферического IPSec в вакууме, который на практике мне не встречался.
Поэтому прошу меня извинить, но я не вижу смысла выбрасывать из своей статьи существенную часть и упрощать её до ещё одной типовой статьи из интернета.
andy, IP-адрес 192.168.81.241 становится новым адресом моста на портах 2-5. IP-адрес 22.22.22.22 становится внешним адресом на порту 1. В статье описывается защита трафика, маршрутизируемого между сетью 192.168.81.240/28 и всеми остальными сетями, доступными через внешний IP-адрес.
Отправить комментарий