Про IPsec для самых маленьких
Набор протоколов IPsec широко используется для защиты сетевых соединений, но он же вызывает наибольшее количество затруднений у начинающих пользователей (и не только).
Очевидный плюс IPsec – высокий уровень надежности и защиты, а дальше пошли сплошные минусы. Как следует из названия IPsec работает на сетевом уровне и использует протокол IP, что делает его универсальным и прозрачным для любых вышестоящих протоколов.
При этом IPsec не плодит никаких лишних сущностей: новых соединений, интерфейсов и т.д. и т.п. Т.е. вы как работали с IP, так и продолжаете работать, а IPsec тихо и незаметно делает свое дело.
Это и обуславливает его широкое распространение, вам не нужно думать о поддержке IPsec со стороны своего сетевого приложения, достаточно того, что оно может работать с IP. И это же является основной сложностью для работающих с ним администраторов.
Правила обработки трафика IPsec задаются политиками и основаны на адресах источника и назначения пакета. Никаких интерфейсов - только адреса, маршрутизация тоже не работает. Точнее она работает, но там, где должна работать, на принятие решения о том, будет зашифрован IP-пакет или нет она не влияет.
IPsec может работать в двух режимах – туннельном и транспортном. Начнем с транспортного, в этом случае шифруется только полезное содержимое IP -пакета, заголовки оставляются в неизменном виде.
Это удобно для защиты трафика между узлами, имеющими внешние IP-адреса, что позволяет шифровать только полезное содержимое и исключить дополнительные накладные расходы.
В туннельном режиме пакет шифруется полностью, со всеми заголовками и помещается внутрь нового пакета, который отправляется второй стороне, указанной в настройках IPsec соединения.
В данном случае IPsec работает как классический туннель с инкапсуляцией пакетов, но то, какие пакеты будут инкапсулированы определяется также политиками, а не маршрутизацией.
А далее такой пакет и неважно туннельный или транспортный режим там используется пойдет, как и любой другой по всем правилам брандмауэра и установленным маршрутам.
Здесь появляется очередная сложность – избежать дополнительной обработки такого пакета брандмауэром и особенно NAT, в противном случае изменятся его адреса источника / назначения, и он перестанет соответствовать политикам IPsec. Все это решаемо, но требует определенных знаний и понимания.
Ну и, наконец, работать IPsec может совершенно на разных уровнях. Например, часто мы говорим, что подняли туннель GRE over IPsec, а кто-то может поднять IPsec over GRE. Казалось бы, какая разница, все равно у нас есть зашифрованный туннель. Но разница есть, и она огромная.
GRE over IPsec обозначает что мы поднимаем GRE-туннель не предусматривающий никакого шифрования поверх уже установленного IPsec соединения между узлами.
Что это значит? А то, что между узлами А и Б при помощи IPsec будет защищен любой IP-трафик, а не только GRE. Вы можете гонять там что угодно и все это будет также защищено при помощи IPsec.
А если мы поднимем IPsec over GRE, то в этом случае мы создаем между узлами А и Б незашифрованный туннель, но все что ходит в этом туннеле и только шифруется с помощью IPsec. Только то, что в туннеле, а не весь трафик между внешними узлами.
Причем право на жизнь имеют обе модели, все зависит от задач, но разница между ними более чем существенна и без понимания таких тонкостей можно наделать откровенно странных конструкций или недоумевать, почему сеть работает не так, как «задумано».
Поэтому перед тем, как бездумно настраивать IPsec уделите время на хотя бы обзорное знакомство с этим набором протоколов, чтобы вы хотя бы на базовом уровне имели представление как это взаимодействует между собой и почему работает именно так, а не иначе.
Post #5971
2.48K