Администрирование IPSec VPN под Linux, примеры конфигураций

Михаил Разумов, по материалам Sys Admin Magazine

IPSec VPN в транспортном режиме (Хост-Хост) – листинг 1(b)

У IPSec есть два режима: транспортный и туннельный. Транспортный режим обеспечивает защиту только дейтаграмм между источником и адресатом. Он аутентифицирует, инкапсулирует, и шифрует только IP данные, но оставляет транспортные заголовки (IP информацию) без изменения (см. рисунки 1(a) и 2(b)). В результате, транспортный режим обычно используется для создания зашифрованных туннелей хост-хост. В листинге 1(b) компьютер с IP 1.2.3.4 соединяется через зашифрованный туннель с другим компьютером, IP 5.6.7.8. Этот пример проиллюстрирован на рис. 3. Строка "auto=start" задает, что туннельное соединение будет установлено при использовании IPSec.

Рис. 3. VPN связь хост-хост в транспортном режиме со статичными IP адресами (листинг 1(b)).

IPSec VPN в туннельном режиме (Подсеть-Подсеть) – листинг 1(c)

В туннельном режиме создается новый IP заголовок и вся оригинальная дейтаграмма инкапсулируется, эффективно скрывая информацию об оригинальном отправителе (рис. 1 и 2(c)). Инкапсуляция позволяет пакетам из одной сети туннелироваться через другие сети. Одно из применений – это использование IPSec шлюзов, соединяющих доверительные частные сети через публичные (напр. Интернет). На рис. 4 показана такая конфигурация.

Рис. 4. VPN связь подсеть-подсеть в туннельном режиме (листинг 1(c) и 1(d))

IPSec VPN в туннельном режиме с RSA аутентификацией – листинг 1(d) и 1(e)

Срок патента на алгоритм RSA истек в сентябре 2000 г., и теперь RSA-аутентификация бесплатно доступна для FreeS/WAN. IPSec использует RSA ключи для аутентификации, но не для шифрования. Симметричные групповые шифры используются на стадии шифрования данных, а ключи для этих шифров распределяются с использованием RSA ключей. RSA аутентификация позволяет сетевым администраторам раздавать публичные RSA ключи всем, кто хочет связаться через IPSec. Похищение публичного ключа не нарушает безопасности, потому что только носитель секретного личного ключа (вероятно, законный владелец ключевой пары) сможет совершить процесс аутентификации. В листинге 1(d) строки rightid и leftid гарантируют, что аутентификация ограничена определенными IP адресами.

Утилита ipsec, запущенная с опцией rsasigkey создает пару ключей публичный-личный в требуемом формате для файла ipsec.secets (детали см. в man для ipsec_rsasigkey). Публичные ключи созданные rsasigkey, могут быть затем вставлены в ipsec.conf и назначены к leftrsasigkey и rightrsasigkey, как в листингах 1(d)-(f). Листинг 2(b) показывает компоненту ipsec.secrets, дополняющую листинг 1(d) с RSA ключами, сгенерированными rsasigkey.

FreeS/WAN также может использовать сертификаты X.509 (используемые обычно для Secure Socket Layer – SSL), которые создаются и распределяются доверенной третьей стороной, называемой certification Authority (CA). Реализация X.509 была разработана независимо от проекта FreeS/WAN и свободно доступна с StrongSec.com. После того, как сертификат сохранен локально на хосте с FreeS/WAN в определенном месте, leftrsasigkey=%cert и leftrsasigkey=%cert задают использование сертификатов. Также доступны утилиты для аутентификации от третьих сторон, основанные на PGPNet.

Метод PSK использует один, взаимный общий секрет как первичный аутентификатор и IP адрес как вторичный аутентификатор. RSA аутентификация требует знания только правильных публичного и частного ключей связывающихся сторон. Таким образом, для установок FreeS/WAN, использующих ключевую пару RSA, фиксированные IP адреса больше не служат идентификторами. В результате, RSA аутентификация может использоваться для аутентификации пользователей, имеющих динамические IP адреса. Листинг 1(e) отображает такую установку, в которой локальный IP адрес шлюза с динамическим IP определяется автоматически (left=%defaultroute).

Строки rightid и leftid используются как дополнительные параметры контроля. Эти строки могут содержать IP адрес (листинг 1(d)), доменное имя (с возможным риском неудачи DNS поиска), и не-DNS имя, начинающееся с “@” (как в листинге 1(f)). Последняя опция – по существу произвольная пара общих ключей. Однако, в отличие от случая PSK аутентификации, безопасность не будет нарушена в случае RSA аутентификации при похищении этой информации.

IPSec VPN “дорожная” конфигурация (Подсеть-Хост) с RSA аутентификацией – листинг 1(f)

Этот вариант практически идентичен варианту 1(e) с разницей в том, что вместо связи подсеть-подсеть, мы создали VPN подсеть-хост (рис. 5). Здесь задана только одна подсеть.

Рис.5. «Дорожная» конфигурация с динамически меняющимся IP адресом (листинг 1(f)).

Обратите внимание, что строка auto=add противоположна auto=start. Туннель не образуется по требованию, а просто устанавливается на стороне со статическим IP в прослушивающее состояние. Этот туннель находится в «спящем» состоянии, и «просыпается», когда к хосту с настройкой auto=add подключается хост с динамическим IP (ноутбук на рис.5), имеющий раздел conn установленный в auto=start.

FreeS/WAN и файрволлы

В примерах, следующих за 1(a), один или оба шлюза FreeS/WAN являются также маршрутизаторами. В большинстве случаев, эти шлюзы будут также и файрволлами. И зачастую эти файрволлы будут выполнять NAT (Network Address Translation – Трансляция Сетевого Адреса).

Создание туннелей FreeS/WAN через какое-либо устройство NAT или IP masquerading (имитации) будет иметь непредсказуемый результат и потому не рекомендуется. Если шлюз IPSec – не та же платформа, которая выполняет NAT/masquerading (т.е. туннель завершается на шлюзе NAT), тогда настойчиво рекомендуется, чтобы шлюз IPSec находился перед платформой NAT/masquerading. По существу, IPSec должен проверять пакеты до того, как они переделаны в NAT. Причина этого в том, что после того, как NAT изменяет IP заголовки пакетов, эти пакеты не проходят проверку целостности IPSec (рис. 1 и 2). Для преодоления этой проблемы предпринимались некоторые попытки, включая IETF Internet Draft (http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-04.txt) и RFC 2709.

FreeS/WAN работает на Linux файрволлах с использованием стандартного ipchains. Также он был протестирован на iptables Linux 2.4 Kernel. Iptables имеют множество новых возможностей для файрволлинга по сравнению с ipchains.

Для нормальной работы Pluto должен быть открыт порт 500 для UDP пакетов на каждом из IPSec шлюзов. ESP использует порт 50; AH – 51. Соответственно должны быть настроены файрволлы. Образцы скриптов для файрволлов, содержащих правила для FreeS/WAN, доступны с веб-сайта FreeS/WAN. Множество заготовок скриптов, например от David Ranch’s TrinityOS или Seattle Firewall Project (SeaWall), содержат специфичные параметры для конфигурирования файрволлов, являющихся IPSec шлюзами. Типичные настройки IPSec работают и для FreeS/WAN.

Вы можете еще больше защитить IPSec VPN, используя в добавление к аутентификационным настройкам FreeS/WAN, ограничение соединений на IP уровне с помощью фильтрации на файрволле. Если, для примера, вам нужно изменить конфигурацию файрволла в зависимости от статуса соединения, вы можете использовать возможность updown в файле ipsec.conf FreeS/WAN, чтобы внести изменения в скрипт ipchains и переконфигурировать таблицы маршрутизации.

Приспосабливающееся шифрование

Для больших систем объединенных шлюзов и хостов, быстрое отслеживание ключей аутентификации становится невозможным. Каждый VPN туннель должен быть тщательно сконфигурирован с соответствующими ключами и информацией о соединяющихся сторонах в разделе conn, на обоих концах каждого туннеля. Рассмотрим сложную запутанную VPN топологию со множеством туннелей, в которой каждая точка может соединяться со всеми другими. Задача ручного добавления и учета всех возможных партнеров на всех системах стремительно усложняется  с увеличением количества удаленных шлюзов.

Последняя версия FreeS/WAN (версия 1.9.1 на момент написания статьи) пытается облегчить некоторые из этих проблем с помощью приспосабливающегося шифрования. Приспосабливающееся шифрование не требует от администраторов IPSec шлюзов договариваться о настройках соединений. Исходящие пакеты анализируются шлюзом IPSec, чтобы убедиться, что зашифрованное соединение с данным адресатом разрешено. Если соединение разрешено, пакет шифруется. Секция conn может выглядеть, как в листинге 1(g), где задана только текущая подсеть.

Адресаты всех исходящих пакетов проверяются на наличие публичного ключа через запись в DNS, публикующую публичные ключи. В обычной реализации DNS с использованием BIND, публичные ключи являются строками, помещенными в доменную TXT запись хоста. Для работы приспосабливающегося шифрования требуется доступ к обратному преобразованию DNS.

Поскольку соединения с DNS серверами основаны на полном доверии и обычно не аутентифицируются, этот способ не может считаться полностью безопасным. Группа безопасности SDNS IETF сейчас разрабатывает спецификацию защищенной DNS системы. Среди усовершенствований – защищенная запись KEY для хранения криптографических публичных ключей. Подробности смотрите в документации по FreeS/WAN 1.9.1 и выше.

Заключение

Распределенные вычисления, растущее число мобильных пользователей сети, и рост количества и возможностей мобильных сетевых устройств подталкивают нас к объединению различных частей сети в одно целое. Есть надежда, что эта статья показала, что проект FreeS/WAN вырос до того, чтобы быть безопасным и расширяемым стандартом для создания VPN сетей.