TOP-10 ошибок при строительстве IPSec-тоннелей
Крик души. Задрали всякие "сетЬевые инжЫнеры" и псевдоадмины, которые совершенно не утруждаются разобраться что творится "под капотом" у тех железок, которые они настраивают, да еще и как правило через уёб-интерфейс или красивый GUI. Нет, в UI/UX нет ничего плохого, только вот до сих пор вспоминаю, как нас первые полтора курса института заставляли чертить руками. Несмотря на то, что в те времена уже существовали всякие там AutoCAD-ы. Почему? А чтобы не просто рисовали линии и окружности, а понимали что именно они означают.
Мне за свою карьеру пришлось построить уже больше сотни всевозможных IPSec-тоннелей на разных железках, софте и их комбинации. Так что могу составить свой персональный "топ-10" ошибок, которые совершают псевдоадмины. И это не баги, а именно нежелание разбираться в процессах, лень и пофигизм.
- Убирают IPSec-терминатор за NAT. Вот за это вообще нужно бить ногами. Больно. Как правило, такое случается преимущественно в банках и обычно по требованию "безопасников". В таком случае подобных безопасников тоже следует бить ногами. Потому что дебилы. И потому что не будет такой IPSec никогда нормально работать без постоянных плясок с бубном. Особенно если он responder. То есть, за его спиной скрываются некие сущности, выступающие в качестве сервера. Например, веб-сервер и иже с ними. Потому что на NAT-шлюзе IKEшные UDP-сессии будут стабильно протухать. И IPSec-гейты не смогут обновить сессионные ключи без полного перезапуска IKE-соединения.
- Не отключают DPD (Dead Peer Detection), он же IKE Keep-Alives. Проблема усугубляется тем, что на цисках он включён по умолчанию. При этом происходит прекрасное. Какое-нибудь кратковременное нарушение сетевой связности приводит к тому, что циска начинает расценивать своего контрагента как дохлого (dead) и обнуляет все связанные с ним IKE SA. А тот про это ничего не ведает. С его точки зрения проблем не возникло, он продолжает шифровать исходящие пакеты прежними сессионными ключами. Циска такой входящий трафик тупо дропает, а её пир про это, опять же, ничего не знает. Вот и ложится тоннель до следующего обмена сессионными ключами. Ну либо до тех пор, пока не пойдёт трафик с другой стороны. А если с этой самой "другой стороны" находятся исключительно серверные приложения, то он никогда оттуда не пойдёт...
- Пытаются резервировать (High Availability) свои IPSec-терминаторы либо посредством DPD (см. пункт 2), либо (что ещё хуже) посредством NAT (см. пункт 1). И обычно никто не догадывается, что в протоколе IKE есть такая штука как "Identity", которая вообще-то у каждого пира должна быть своя собственная и уникальная. Единственный (слышите, единственный) надёжный способ резервировать IPSec-каналы - это построить два одновременно работающих тоннеля и организовать динамическую маршрутизацию внутри них (OSPF, BGP, whatever). Всё. Точка. Всё остальное - это гнилое дрочерство, не имеющее ничего общего с надёжностью, типа заземления в цветочный горшок.
- Навешивают на "внешний" и "внутренний" концы тоннеля один и тот же IP-адрес. Формально это не запрещено. И циска так делать вполне себе позволяет. Но если с другой стороны не циска, ждите проблем. Разбираться что же пошло не так будете очень долго.
- Не навешивают вообще никакого IP-адреса на внутренний конец тоннеля. Всё то же самое, что и в предыдущем пункте. Плюс усложнение диагностики и мониторинга (что это?).
- Используют при настройке policy-based парадигму. Когда маршрутизаторы были большими, а интернет маленьким, IPSec-тоннели настраивались политиками FireWall-а и прочими ACL-ями. С тех пор много воды утекло. Прогрессивные железки давно ушли на route-based концепцию, то есть настройку тоннелей в терминах маршрутов. Только мамкины админы как один раз прочитали написанный кем-то в 199x-мохнатом году Howto-шку, так и продолжают клепать эти тоннели на политиках, да ещё и с 3Des и MD5 внутри.
- Искренне уверены, что криптодомен (он же IPSec SA) и маршрут (route) - это одно и то же. И что нельзя делать их разными. Ну тут медицина бессильна, сразу в морг.
- Как следствие предыдущего пункта, плодят криптодомены в количествах, по одному "/32" на каждый защищаемый шифрованием хост. Часто объясняют данную вакханалию "безопасностью". Хотя оной тут даже близко не пахнет. Зато получаем раздувшиеся до циклопических размеров конфиги и огромные трудности с мониторингом. Потому что легко может случиться, что часть этих IPSec SA приляжет, а другая часть останется. При этом виртуальный интерфейс на маршрутизаторе будет рапортовать что он живой, пока активна хотя бы одна IPSec SA. Вот и как всю эту радость мониторить для обеспечения SLA? А хрен его знает, товарищ прапорщик.
- Не отключают Idle Timeout. На цисках он по умолчанию включен. Вот спрашивается, вам что, жалко что ли пару десятков байт в оперативной памяти на поддержание штанов тоннеля в активном состоянии? Зато у контрагента IPSec-интерфейс будет регулярно "флапать" при отстутствии трафика. Оно вам надо?
- Не используют IKEv2 и AEAD-шифры, хотя железка и прошивка позволяют это делать. Мотивируют обычно "коПРоративными стандартами", хотя на практике это переводится как "нам лень разбираться с новыми технологиями, отвали". Тут тоже только в морг.