OpenVPN 2.0: переводим клиента с IPSec и разбираемся с сертификатами

Сегодня выкатили OpenVPN 2.0.8 - точечное обновление с обновлением OpenSSL до 0.9.7k, закрывающим уязвимость RSA Signature Forgery (CVE-2006-4339). Хороший повод написать о том, что мы делаем с этим инструментом последний год.

Один из клиентов, которых мы сопровождаем, пришёл к нам с вопросом: офис в Москве и небольшой склад в Подмосковье соединены IPSec-туннелем через два потребительских роутера. Туннель падает раз в несколько дней, после чего кто-то должен физически перезагрузить оборудование на складе - там нет своего специалиста. Плюс на складе NAT, и с согласованием фаз IPSec при смене внешнего IP провайдер регулярно что-то ломает.

Мы предложили перейти на OpenVPN. Клиент поморщился - «это же для хакеров какой-то», - но согласился послушать.

Почему IPSec здесь проигрывает

IPSec - протокол серьёзный, в корпоративных сетях работает отлично, когда обе стороны под контролем и без NAT. Но в сценарии «два офиса, один из которых за NAT провайдера» он превращается в постоянную борьбу с окружением.

Конкретные проблемы, с которыми мы сталкиваемся:

• NAT traversal (NAT-T) - работает, но не везде и не всегда. Часть провайдеров режет UDP 4500, часть - 500. Диагностика при падении туннеля сводится к гаданию: это NAT-T, это DPD, это провайдер, или просто роутер завис.
• Phase 1/Phase 2 рассинхрон - при смене внешнего IP или сбое связи туннель не всегда переподнимается автоматически. У дешёвых роутеров реализации IKE разные, совместимость - лотерея.
• Логи - на потребительском железе их почти нет. Когда туннель падает, понять почему можно только включив packet dump на обеих сторонах одновременно.

OpenVPN работает поверх TCP или UDP на обычном порту. Через NAT ходит без вопросов - это просто TLS-соединение с точки зрения промежуточного оборудования. Клиент всегда инициирует соединение наружу, сервер слушает на фиксированном порту. Логи читаемые, с временными метками и понятными сообщениями об ошибках.

Сертификаты вместо паролей

OpenVPN поддерживает оба варианта - и pre-shared key (tls-auth), и PKI с сертификатами. Для серьёзного применения мы используем PKI: собственный CA, отдельный сертификат на каждый узел.

Схема такая: разворачиваем лёгкий CA с помощью easy-rsa (идёт в комплекте с OpenVPN), выпускаем корневой сертификат CA, потом по одному сертификату на сервер и на каждого клиента. При подключении обе стороны проверяют сертификат друг друга - это взаимная аутентификация, а не просто «клиент знает пароль».

Главное практическое преимущество: отозвать доступ конкретному узлу можно без перенастройки остальных. Добавляем сертификат в CRL (Certificate Revocation List) на сервере - этот клиент больше не подключится. При IPSec с shared key так не сделаешь: смена ключа требует перенастройки обеих сторон.

Для клиента со складом выпустили три сертификата: для московского сервера, для склада и отдельный для ноутбука директора, который иногда работает удалённо. Три узла, три сертификата, один CA.

Три топологии, которые мы накопили

За год работы с OpenVPN у нас сложились шаблоны конфигов для трёх сценариев, которые встречаются чаще всего.

Офис-офис (site-to-site). Один из офисов - сервер (слушает UDP 1194), второй - клиент, который инициирует соединение. Режим dev tun, маршруты в обе подсети прописаны явно через route в конфиге. При падении связи клиент переподнимает соединение автоматически - параметр keepalive 10 60 и persist-tun. Туннель встаёт сам, без перезагрузки оборудования.

Роуд-воррior (удалённые сотрудники). Сервер с server 10.8.0.0 255.255.255.0 раздаёт клиентам адреса из пула. Каждый клиент получает свой IP внутри VPN, видит только нужные ресурсы через push "route ...". Сертификат - на человека, а не на устройство. Уволился сотрудник - сертификат в CRL, доступ закрыт.

Филиал-ЦОД. Здесь сервер стоит в ЦОД с белым IP, к нему подключаются несколько филиалов. Каждый филиал - отдельный клиентский конфиг в ccd/ (client-config-dir), там прописана подсеть этого филиала через iroute. Сервер знает, за каким клиентом какая подсеть, и маршрутизирует трафик между филиалами через себя. Работает, хотя при большом количестве филиалов трафик идёт через ЦОД даже там, где он мог бы идти напрямую - это осознанный компромисс ради простоты управления.

Что в итоге у клиента

Туннель между офисом и складом поднялся с первой попытки. NAT на стороне склада не потребовал никаких специальных настроек - склад просто инициирует исходящее UDP-соединение. Уже неделя без падений.

Логи на сервере читаются нормально: видно когда клиент подключился, с какого IP, какой сертификат предъявил. Это уже сравнимо с тем, что мы видели в настройке WPA2-Enterprise - аудит по пользователям, а не по IP.

Для клиентов, которых мы ведём в рамках управляемого обслуживания, шаблоны конфигов OpenVPN теперь лежат у нас в репозитории - берём нужную топологию, правим адреса и имена, выпускаем сертификаты. На разворачивание нового туннеля уходит час вместо дня на согласование IPSec-фаз.

Версия 2.0.8 - не революция, но обновление OpenSSL лишним не бывает. В site-to-site сценарии туннель должен держаться неделями без вмешательства, и с этим у OpenVPN пока выходит лучше, чем у IPSec на потребительском железе.