Д. Ю. ОКУНЕВ
Национальный исследовательский ядерный университет «МИФИ»
ОПЫТ ВНЕДРЕНИЯ VPN ДЛЯ ОРГАНИЗАЦИИ ДОСТУПА
В ИНТЕРНЕТ
Рассматриваются вопросы организации VPN на базе Linux и FreeBSD в сети с большим количеством пользователей.
В рамках проекта по созданию и развитию сети в общежитии НИЯУ МИФИ необходим механизм авторизации пользователей для доступа в Интернет и логирования данных о их трафике.
Были изучены различные варианты реализации авторизируемого доступа в Интернет. В рамках уже существующей на тот момент сети, наиболее разумными технологиями были выбраны L2TP (с возможностью использования IPSec) и PPTP. Данные протоколы были выбраны из-за широкой поддержки в пространстве ядра (kernel-space) популярных дистрибутивов операционных систем (ОС), простой настройке в системах из семейства «Windows» и условиями функционирующей локальной вычислительной сети в общежитии НИЯУ МИФИ.
Для реализации проекта было необходимо выполнить следующие этапы:
ñ Реализовать PPTP-сервер.
ñ Реализовать L2TP-сервер.
ñ Реализовать поддержку IPSec с авторизацией по сертификатам.
ñ Реализовать авторизацию через несколько LDAP-серверов.
ñ Реализовать запоминание «туннельных» IP-адресов и ограничение количества параллельных соединений для одного пользователя.
ñ Реализовать shaping.
ñ Реализовать firewall, достаточно мощный, чтобы справиться с общим потоком трафика.
ñ Провести оптимизацию.
ñ Составить инструкции.
ñ Реализовать отказоустойчивость и распределение нагрузки для всех перечисленных этапов.
ñ Настроить маршрутизацию на стороне клиентов.
Для реализации PPTP был опробован ряд технологий:
ñ poptop pptpd на Linux;
ñ accel-pptpd на Linux;
ñ accel-ppp на Linux;
ñ mpd5 на FreeBSD.
Выбран был Accel-pptpd методом исключения по следующим причинам:
ñ Poptop pptpd работал слишком малопроизводительно из-за того, что вымещал большое количество операций в пространство пользователя (user-space).
ñ Accel-ppp является достаточно качественным продуктом, но слишком «сырым». В частности, в accel-ppp неверно вычислялись magic number-ы из-за неучёта разницы bigendian и littleendian записей 4-октетного числа. Был написан «patch» для устранения этой проблемы, однако при высокой нагрузке accel-ppp давал сбой, в среднем, раз в сутки.
ñ Mpd5 тоже является качественным продуктом. Однако mpd5 работает на FreeBSD, в которой на тот момент нагрузка при работе VPN по mpd5 почти не распределялась по процессорам.
Для реализации L2TP был опробован следующий ряд технологий:
ñ xl2tpd;
ñ openl2tpd;
ñ accel-ppp;
ñ mpd5.
Аналогично с PPTP, выбран был openl2tpd методом исключения по причинам:
ñ Xl2tpd работает в user-space.
ñ Accel-ppp - слишком «сырой» для применения в подобных масштабах.
ñ Mpd5 - неэффективно использует SMP в ядре FreeBSD для таких задач.
Основными недостатками openl2tpd является плохая документация и «сырая» реализация. В частности, использование openl2tpd на ядрах из семейства 3.x приводило к систематическим kernel panic при высоких нагрузках. Проблема была устранена применением специального патча на ядро системы и дальнейшей рекомпиляции.
Аналогично, для реализации поддержки IPSec были опробованы технологии:
ñ strongswan;
ñ openswan;
ñ ipsec-tools (libipsec, setkey, racoon).
Сначала был опробован strongswan. Однако strongswan не имеет поддержки нескольких L2TP клиентов за одним NAT-ом, из-за чего был опробован openswan. Openswan работал и почти всем подходил, однако решение с использованием ipsec-tools оказалось более простым в сопровождении, из-за чего с расчётом на потенциальную передачу сопровождения проекта другим специалистам, openswan был заменён на ipsec-tools.
Далее было необходимо раздать сертификаты конечным клиентом, для чего был создан ресурс по автоматической генерации и подписи электронных сертификатов.
Для пользователей windows xp, не желающих использовать ipsec для l2tp, была предоставлена инструкция по отключению использования ipsec.
В ранее сформированной системе базы студентов/аспирантов и сотрудников были доступны через два разных LDAP-ресурса. К тому же, используя accel-pptpd и openl2tpd нет прямой возможности использовать LDAP для авторизации пользователей. Для решения данной проблемы был поднят radius-сервер, который проверяет реквизиты пользователей по обоим LDAP-ресурсам.
Немаловажной проблемой является возможность вести учёт данных по трафику «кто, куда, что слал». Наиболее общепринятым решением для этого является использование netflow-сенсора и netflow-коллектора. На маршрутизаторе после VPN-серверов устанавливается netflow-сенсор, который, соответственно, отправляет данные к netflow-коллектору. При использовании данной схемы имеется проблема, связанная с тем, что если выдавать по VPN адреса из обычного динамического pool-а адресов, то по логам может оказаться проблематичным однозначно определить, кто именно отсолал какой-то конкретный пакет. Для того, чтобы не реализовывать комплексные механизмы согласования логов radius-а или VPN-серверов о временах подключения/отключения конкретных пользователей в конкретные моменты времени с данными netflow-коллектора, которые могут являются источником неполадок, было принято решение закреплять адреса за пользователями после первого использования. Для radius-сервера был поднят MySQL сервер, в котором хранились данные о том, «кто/когда» подключался (лог подключений), таблица «текущих подключений» и таблица в которой закреплены IP-адреса за конкретными логинами. Был написан ряд хранимых MySQL-функций и процедур для выделения, освобождения, ведения учёта и прочее выдываемых IP-адресов. После чего radius-сервер был настроен таких образом, чтобы выдавать IP-адреса, используя данные MySQL функции. Так же было введено ограничение максимум на два параллельных соединения с одного логина.
Далее требовалось реализовать честное деление канала между пользователями. В результате был организован нехитрый алгоритм, который честно делит канал по технологии HTB в Linux. Однако были так же опробованы dymmnet во FreeBSD и TBF в Linux. Dummynet работал весьма успешно, но как уже оговаривалось ранее, во FreeBSD малоэффективно используется многопроцессорность, из-за чего данная технология оказалась неприменимой. А TBF, используемый по умолчанию в accel-pptpd, давал слишком низкую пропускную способность при любой конфигурации.
В процессе эксплуатации при увеличенной нагрузке выяснилось, что штатный FWSM не справляется с NAT-ированием столь интенсивного потока трафика (>600Mibps) с использованием столь большого количества сетевых сессий (>300000). Для решения этой проблемы был поднят отдельный NAT-ирующий маршрутизатор на базе HP Proliant DL360G7. Так же, на данном сервере был скомпилирован и установлен kernel-space netflow-сенсор «ipt_NETFLOW». На данный момент, пиковая нагрузка с использованием всех оптимизаций на данный поток составляет ~30%.
Испытывался ряд методов оптимизации. Основные моменты:
ñ Была попытка запустить FreeBSD с достаточно эффективным распределением нагрузки по ядрам, на базе threadirq (и RPS), с использованием технологии виртуализации XEN. FreeBSD был поднят в качестве гостя на Linux хосте, где распределение нагрузки по ядрам уже производилось на родительской системе. Однако, как уже было замечено, данный метод оказался несостоятельным.
ñ RPS показал ощутимое повышение производительности (вместо двух ядер используются все)
ñ внесение очевидных правок в sysctl-настройки показало малозаметное повышение производительности
ñ Повышение hashsize-а для nf привело к значительному повышению производительности. Поиск по conntrack в Linux изначально мало зависит от количества активных сессий (в теории должна быть логарифмическая зависимость), однако после преодоления некоторого порогового количества записей время поиска начинает экспоненциально расти. Более того, значение этого порогового количества записей, как показала практика, зависит от нагрузки системы другими процессами. Возможно, такая зависимость обусловлена архитектурными особенностями компьютера (например, недостатком кеша L2 или L3) или внутренними архитектурными особенностями ядра Linux. Это являлось причиной разделения NAT-ирующего маршрутизатора и VPN-серверов на разные физические машины.
ñ Произведена пересборка ядра Linux с учётом требования высокой производительности в качестве VPN-сервера и маршрутизатора, а также с учётом используемой архитектуры компьютера.
ñ Firewall-ы на VPN-серверах были переведены в stateless режим, используя действие «NOTRACK» в «raw/PREROUTING», что показало значительное повышение производительности.
Составлены инструкции для Windows XP и опубликованы на сайте на базе «mediawiki». Написан специальный легковесный «демон», который на любой http-запрос перенаправляеи на данный сайт. Настроена маршрутизация так, чтобы трафик в Интернет в обход VPN-сервера попадал на сервер, где поднят перенаправляющий «демон» и настроено перенаправление на него HTTP-трафика. В результате, клиент, который пытается просмотреть какую-то web-страницу в обход VPN-сервера, перенаправляется на сайт с инструкциями по настройки VPN-подключений.
Немаловажным шагом является реализация отказоустойчивости всей данной системы. Для реализации отказоустойчивости использовались технологии VRRP и CARP и избыточность серверов. Для балансировки нагрузки использовалась технология DNS-rr (DNS round robin).
Также целесообразно организовать пользователей сообщаться напрямую друг с другом в обход VPN-серверов. С этой целью на DHCP-серверах в соответствии с RFC3442 и рекомендациями о динамической настройки маршрутизации в системах из семейства «Windows» были добавлены соответствующие DHCP-опции, для указания специальных маршрутов до сетей, определённых в RFC1918 как «private» (10/8, 172.16/12, 192.168/16). Теоретически, при подключении к VPN после замены default gateway на клиентских компьютерах для локальной сети должны были быть приоретитными данные маршруты. Эксперимент показал, что на многих ОС из семейства «Windows» наблюдается иное поведение. Далее, в соответствии со спецификацией на support. (kb/299540) об «автоматическом назначении метрики маршрутов протокола IP» предполагалось, что если выставлять достаточно низкую скорость канала, то метрика должна будет выставиться достаточно высокой, чтобы основным маршрутом был не через VPN, а выданный по DHCP, однако аналогично и предыдущей попытке, реакция ОС из семейства «Windows» оказалось иной. В результате был написан bat-скрипт, который, анализируя вывод команды «route print», решает какие маршруты нужно добавить и добавляет их через «route add».
Долгое время наблюдались проблемы с произвольными отключениями клиентов от VPN-серверов, вызванные перенагруженность промежуточных маршрутизаторов. После разгрузки данных маршрутизаторов пользователи сети по инерции продолжают считать, что проблема on server-side (а не on client-side). Однако по обработке звонков технической поддержки сети общежития выясняется, что дальнейшие проблемы вызваны либо недостаточно надёжным wi-fi линком, либо использованием дешёвых NAT-ирующих маршрутизаторов, либо проблемами конкретной ОС и т. п. На данный момент в пике, обслуживается порядка 4000 одновременных соединений с потоком в 650Mibps. Избыточная мощность в штатном состоянии на VPN-серверах составляет 60-70%, а на NAT-е — 85%.
