IPSec между офисами: когда железо делает то, что раньше делал сервер

Прошлым летом мы связали два офиса клиента через VPN поверх ШПД и остались этим решением в целом довольны. Туннель поднимался на сервере, шифрование делалось там же, всё работало. Но была одна деталь, которая постепенно начала раздражать: под нагрузкой сервер заметно загружался именно на шифровании. Не критично, но заметно. А у клиента трафик между офисами рос - 1С, почта, файлы.

В этом месяце мы заменили программный туннель на аппаратный IPSec между маршрутизаторами. Разница оказалась ощутимее, чем мы рассчитывали.

Что было раньше

Туннель жил на обычном Linux-сервере с OpenVPN. Схема надёжная и хорошо знакомая. Сервер занимался примерно десятком задач помимо туннеля: файловая шара, DNS, прокси. Шифрование туннеля добавляло нагрузку, которая при пиковом трафике между офисами давала о себе знать - загрузка процессора подскакивала, и всё остальное на сервере начинало думать чуть медленнее.

Плюс архитектурная нелепость: трафик между офисами делал лишний хоп через сервер. Пакет из второго офиса прилетал не напрямую в сеть, а сначала на сервер, там расшифровывался и потом уже шёл куда надо. Задержки были небольшие, но они были.

Что поставили

На оба конца встали маршрутизаторы с аппаратным IPSec - железки с отдельным чипом для шифрования. Туннель теперь поднимается между ними, сервер в схеме вообще не участвует.

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

Что изменилось

Нагрузка на сервер. Ушла в ноль в части шифрования. Сервер снова занимается тем, чем должен: файлами, DNS и прочим. Это само по себе было бы достаточной причиной для замены.

Задержки. Упали примерно в полтора раза по показаниям ping между офисами. Лишний хоп через сервер исчез - трафик теперь идёт прямо маршрутизатор в маршрутизатор.

Пропускная способность. Аппаратный чип не создаёт узкого места. Раньше при активном копировании файлов между офисами сервер начинал немного «жевать» - теперь канал упирается в сам ШПД, а не в процессор.

Надёжность туннеля. Это неожиданный бонус. Маршрутизатор с аппаратным IPSec поднимает туннель при старте и держит его сам, без того чтобы кто-то смотрел за демоном на сервере. Если канал моргнул - железка пересогласовала туннель автоматически. С OpenVPN мы пару раз ловили ситуацию, когда канал упал, демон завис, и туннель не поднялся сам.

Когда программный туннель достаточен

Мы не считаем, что аппаратный IPSec - это всегда правильный ответ. Программный туннель имеет смысл оставить когда:

• Офис маленький, трафик между точками небольшой и сервер не чувствует нагрузки от шифрования.
• Временная связка - надо быстро поднять туннель на том, что есть, без закупки железа.
• Нестандартная топология - несколько точек, road warriors, клиенты с ноутбуков. OpenVPN тут гибче, маршрутизаторы с IPSec часто заточены под site-to-site и с клиентскими подключениями возятся хуже.
• Бюджет нулевой. Нормальный маршрутизатор с аппаратным IPSec стоит денег. OpenVPN на имеющемся сервере - ноль рублей прямо сейчас.

Когда пора на железо

Момент перехода обычно виден довольно чётко:

• Сервер загружен на шифровании при обычном трафике. Если под нагрузкой процессор уходит в 40-60% только на туннель - это сигнал.
• Трафик между офисами стал постоянным и объёмным. Когда люди активно работают с файлами и базами через туннель, а не просто изредка проверяют почту - аппаратный чип отбивает себя быстро.
• Туннель нужен как отдельная надёжная инфраструктура, независимо от состояния серверов. Если сервер перегружается или уходит на обслуживание - программный туннель падает вместе с ним.

Наш клиент попал в третий пункт: у него 1С тянет данные через туннель постоянно, и когда сервер начал тормозить, тормозила и 1С. Делить нагрузку на несколько серверов - дороже, чем поставить нормальный маршрутизатор.

Что это значит для нас в обслуживании

Теперь туннель - это часть сетевого периметра, а не часть серверной инфраструктуры. Мониторим его как сетевое устройство: доступность, задержка, счётчики пакетов. В рамках управляемой инфраструктуры это удобно - меньше точек отказа на серверах, больше предсказуемости в сети.

Единственное, с чем мы ещё возимся - логирование событий с маршрутизаторов. С сервера логи писались куда надо автоматически, с железной коробки надо настраивать syslog отдельно. Мелочь, но при первом развёртывании мы про это забыли и потом гадали по косвенным признакам, почему туннель пересогласовал ключи ночью.