Xfrm linux что это

Обновлено: 01.07.2024

IPsec – это набор протоколов, использующихся для обеспечения сервисов приватности и аутентификации на сетевом уровне модели OSI. Эти протоколы можно разделить на два класса – протоколы защиты передаваемых данных (AH, ESP) и протоколы обмена ключами (IKE).

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

Для установления безопасных Интернет сессий необходимы однонаправленные Secure associations (SA) между участниками соединений. SA определяют, какие операции должны применяться к пакету. Они определяют: метод аутентификации, алгоритм шифрования, ключи шифрования и аутентификации, время жизни ключа шифрования, время жизни SA и номер последовательности (sequence number) для предотвращения повторений.

Secure associations могут быть установлены вручную или автоматически. Для автоматического установления SA используется IKE.

AES (Advanced Encryption Standard), также известный как Rijndael — симметричный алгоритм блочного шифрования (размер блока 128 бит, ключ 128/192/256 бит), принятый в качестве стандарта шифрования правительством США по результатам конкурса AES. По состоянию на 2009 год AES является одним из самых распространённых алгоритмов симметричного шифрования.

DES (Data Encryption Standard) — симметричный алгоритм шифрования, разработанный фирмой IBM и утвержденный правительством США в 1977 году как официальный стандарт (FIPS 46-3). DES имеет блоки по 64 бита и 16 цикловую структуру сети Фейстеля, для шифрования использует ключ с длиной 56 бит. Алгоритм использует комбинацию нелинейных (S-блоки) и линейных (перестановки E, IP, IP-1) преобразований.

3DES (Triple Data Encryption Standard) — симметричный блочный шифр, созданный Уитфилдом Диффи, Мартином Хеллманом и Уолтом Тачманном в 1978 году на основе алгоритма DES, с целью устранения главного недостатка последнего — малой длины ключа (56 бит), который может быть взломан методом полного перебора ключа. Скорость работы 3DES в 3 раза ниже, чем у DES, но криптостойкость намного выше — время, требуемое для криптоанализа 3DES, может быть в миллиард раз больше, чем время, нужное для вскрытия DES. 3DES используется чаще, чем DES, который легко ломается при помощи сегодняшних технологий (в 1998 году организация Electronic Frontier Foundation, используя специальный компьютер DES Cracker, вскрыла DES за 3 дня). 3DES является простым способом устранения недостатков DES. Алгоритм 3DES построен на основе DES, поэтому для его реализации возможно использовать программы, созданные для DES.

RSA ( Ron Rivest, Adi Shamir, and Leonard Adleman Algorithm) — криптографический алгоритм с открытым ключом. RSA стал первым алгоритмом такого типа, пригодным и для шифрования, и для цифровой подписи. Алгоритм используется в большом числе криптографических приложений.

Certificate — цифровой или бумажный документ, подтверждающий соответствие между открытым ключом и информацией, идентифицирующей владельца ключа. Содержит информацию о владельце ключа, сведения об открытом ключе, его назначении и области применения, название центра сертификации и т. д.

Certificate Authority (англ. Certification authority, CA) — это организация или подразделение организации, которая выпускает сертификаты ключей электронной цифровой подписи, это компонент глобальной службы каталогов, отвечающий за управление криптографическими ключами пользователей. Открытые ключи и другая информация о пользователях хранится удостоверяющими центрами в виде цифровых сертификатов.

PKI (Public Key Infrastructure, Инфраструктура открытых ключей) — технология аутентификации с помощью открытых ключей. Это комплексная система, которая связывает открытые ключи с личностью пользователя посредством удостоверяющего центра (УЦ).

CRL (Certificate Revocation list) — Список отозванных сертификатов

Internet Key Exchange (IKE) – протокол использующийся для автоматического создания, установления, изменения и удаления Security Associations (SA) между двумя хостами в сети. SA содержат информацию для установления безопасного соединения между участниками предопределенным способом. IKE основан на протоколах ISAKMP, Oakley и SKEME.

ISAKMP – определяет концепцию управления и обмена ключами, управления и установления SA. IKE – это реализация концепции ISAKMP для использования с IPsec.

ISAKMP определяет процедуры аутентификации участников, создания и управления SA, определяет техники генерации ключей и обеспечения защиты от угроз.

Работа ISAKMP разбивается на две отдельные фазы. Во время первой фазы для защиты дальнейших коммуникаций между участниками устанавливаются ISAKMP SA. Во время второй фазы устанавливаются SA для IPsec.

Одно ISAKMP SA может использоваться для нескольких security associations других протоколов.

Протокол Oakley описывает серии обмена ключами, называемые режимами (modes), и детализирует сервисы предоставляемые каждым режимом (такие как perfect forward secrecy для ключей, защита подлинности, аутентификации). В основе работы протокола лежит алгоритм обмена ключами Diffie-Hellman.

Diffie-Hellman— это метод установки разделяемого ключа в небезопасной среде.

Режим IKE New Group используется для установки новых групп.

IKE не реализует протокол Oakley. IKE использует только подмножество функций необходимых для достижения своих целей, но не является полным соответствием спецификации Oakley. У IKE нет никакой зависимости от Oakley.

SKEME определяет обмен ключами, который обеспечивает анонимность и быстрое обновление ключей.

IKE не реализует весь протокол SKEME. IKE использует только криптографическую систему с открытым ключом и концепцию SKEME быстрой замены ключа с использованием обмена nonces. У IKE нет никакой зависимости от SKEME.

Фазы в IKE такие же как фазы в ISAKMP. Во время первой фазы создаются IKE SA для защиты второй фазы, а во время второй фазы создаются SA для IPsec.

Фаза Xauth (опциональная)

Участники могут меняться ролями между фазами. Инициатор первой фазы может быть ответчиком во время второй фазы.

Для установления IKE SA на первой фазе существует два режима: Основной режим (Main Mode) и Агрессивный режим (Aggressive Mode). Агрессивный режим немного быстрее, но он не обеспечивает защиту подлинности. Основной режим основан на identity protection exchange ISAKMP и обеспечивает защиту подлинности.

На второй фазе для установки SA используется Быстрый режим (Quick Mode).

Кроме того, существует Режим новой группы (New Group Mode), который не является режимом первой или второй фазы. Он используется для установки новой Oakley Group для обмена ключами Diffie-Hellman.

(Main mode) реализует стандартный механизм установления «канала» ISAKMP SA. Он включает в себя три процедуры двунаправленного обмена. Сначала стороны договариваются о базовых алгоритмах и используемых методах хеширования. Затем осуществляется обмен открытыми ключами в рамках алгоритма Диффи — Хеллмана и случайными числами (nonce), которые подписываются принимающими сторонами и отправляются обратно для идентификации. Наконец, в ходе третьего обмена по пришедшим обратно подписанным значениям nonce проверяется подлинность сторон.

Perfect Forward Secrecy позволяет удостовериться, что ключи, которые используются на второй фазе (то есть, для защиты данных), не были получены из ключей на первой фазе. При включенном PFS во время второй фазы выполняется генерация нового ключа с помощью алгоритма DH. PFS DH Group - длина ключа PFS.

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

Аутентификация осуществляется за счет вычисления хэш-функции IP пакета (поля, которые могут меняться в процессе передачи пакета (например, TTL) исключаются). Вычисленная хэш-функция добавляется к заголовку пакета AH и отправляется получателю пакета.

Заголовок AH содержит поле Integrity Check Value, которое вычисляется по алгоритмам MD5 или SHA-1. На практике чаще используется HMAC (Hash Message Authentication Code), так он при вычислении хэш-функции использует заранее известный участникам секретный ключ. В свою очередь HMAC использует для вычисления хэш-функции алгоритмы MD5 или SHA-1. В зависимости от используемого алгоритма HMAC будет называться соответственно HMAC-MD5 или HMAC-SHA-1.

ESP - Протокол безопасности, который обеспечивает конфиденциальность и защиту данных. Возможно использование аутентификации (AH) и обнаружение повторных пересылок. ESP полностью инкапсулирует пакеты. ESP может применяться сам по себе, либо с использованием AH.

Существует два режима работы IPsec: транспортный режим и туннельный режим.

Существуют Linux-команды, которые всегда должны быть под рукой у системного администратора. Эта статья посвящена 7 утилитам, предназначенным для работы с сетью.

Этот материал — первый в серии статей, построенных на рекомендациях, собранных от множества знатоков Linux. А именно, я спросил у наших основных разработчиков об их любимых Linux-командах, после чего меня буквально завалили ценными сведениями. А именно, речь идёт о 46 командах, некоторые из которых отличает тот факт, что о них рассказало несколько человек.

В данной серии статей будут представлены все эти команды, разбитые по категориям. Первые 7 команд, которым и посвящена эта статья, направлены на работу с сетью.

Команда ip

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

Синтаксис этой команды выглядит так:

Самое важное тут — это <OBJECT> (подкоманда). Здесь можно использовать, помимо некоторых других, следующие ключевые слова:

address — адрес протокола (IPv4 или IPv6) на устройстве.
tunnel — IP-туннель.
route — запись таблицы маршрутизации.
rule — правило в базе данных политики маршрутизации.
vrf — управление виртуальными устройствами маршрутизации и перенаправления трафика.
xfrm — управление IPSec-политикой.

Вывод IP-адресов, назначенных интерфейсу на сервере:

Назначение IP-адреса интерфейсу, например — enps03 :

Удаление IP-адреса из интерфейса:

Изменение статуса интерфейса, в данном случае — включение eth0 :

Изменение статуса интерфейса, в данном случае — выключение eth0 :

Изменение статуса интерфейса, в данном случае — изменение MTU eth0 :

Изменение статуса интерфейса, в данном случае — перевод eth0 в режим приёма всех сетевых пакетов:

Добавление маршрута, используемого по умолчанию (для всех адресов), через локальный шлюз 192.168.1.254, который доступен на устройстве eth0 :

Добавление маршрута к 192.168.1.0/24 через шлюз на 192.168.1.254:

Добавление маршрута к 192.168.1.0/24, который доступен на устройстве eth0 :

Удаление маршрута для 192.168.1.0/24, для доступа к которому используется шлюз 192.168.1.254:

Вывод маршрута к IP 10.10.1.4:

Команда ifconfig

Команда ifconfig до определённого времени представляла собой один из основных инструментов, используемых многими системными администраторами для настройки сетей и решения сетевых проблем. Теперь ей на замену пришла команда ip , о которой мы только что говорили. Но если вас, всё же, интересует эта команда, можете взглянуть на данный материал.

Команда mtr

MTR (Matt's traceroute) — это программа, работающая в режиме командной строки, представляющая собой инструмент для диагностики сетей и устранения сетевых неполадок. Эта команда совмещает в себе возможности ping и traceroute . Она, как traceroute , может выводить сведения о маршруте, по которому сетевые данные идут от одного компьютера к другому. Она выводит массу полезных сведений о каждом шаге маршрутизации, например — время ответа системы. Благодаря использованию команды mtr можно получить довольно подробные сведения о маршруте, можно обнаружить устройства, которые вызывают проблемы при прохождении данных по сети. Если, например, наблюдается рост времени ответа системы, или рост числа потерянных пакетов, это позволяет с уверенностью говорить о том, что где-то между исследуемыми системами возникла проблема с сетевым соединением.

Синтаксис команды выглядит так:

Рассмотрим несколько распространённых способов применения mtr .

Если вызвать эту команду, указав лишь имя или адрес хоста — она выведет сведения о каждом шаге маршрутизации. В частности — имена хостов, сведения о времени их ответа и о потерянных пакетах:

Вот — вариант использования mtr , когда вместо имён хостов выводятся их IP-адреса (речь идёт о ключе -g , благодаря которому вместо имён выводятся числовые IP-адреса):

А следующий вариант команды позволяет выводить и имена, и IP-адреса хостов:

А так можно получить отчёт, содержащий результаты работы mtr :

Вот — ещё один вариант получения такого отчёта:

Для того чтобы принудительно использовать TCP вместо ICMP — надо поступить так:

А вот так можно использовать UDP вместо ICMP:

Вот — вариант команды, где задаётся максимальное количество шагов маршрутизации:

Так можно настроить размер пакета:

Для вывода результатов работы mtr в формате CSV используется такая команда:

Вот — команда для вывода результатов работы mtr в формате XML:

Команда tcpdump

Утилита tcpdump предназначена для захвата и анализа пакетов.

Установить её можно так:

Прежде чем приступить к захвату пакетов, нужно узнать о том, какой интерфейс может использовать эта команда. В данном случае нужно будет применить команду sudo или иметь root-доступ к системе.

Если нужно захватить трафик с интерфейса eth0 — этот процесс можно запустить такой командой:

Или — такой, с указанием (через ключ -c ) количества пакетов, которые нужно захватить:

▍ Захват трафика, идущего к некоему хосту и от него

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

Для захвата трафика, идущего с хоста 8.8.8.8, используется такая команда:

Для захвата трафика, уходящего на хост 8.8.8.8, применяется такая команда:

▍ Захват трафика, идущего в некую сеть и из неё

Трафик можно захватывать и ориентируясь на конкретную сеть. Делается это так:

Ещё можно поступить так:

Можно, кроме того, фильтровать трафик на основе его источника или места, в которое он идёт.

Вот — пример захвата трафика, отфильтрованного по его источнику (то есть — по той сети, откуда он приходит):

Вот — захват трафика с фильтрацией по сети, в которую он направляется:

▍ Захват трафика, поступающего на некий порт и выходящего из некоего порта

Вот пример захвата трафика только для DNS-порта по умолчанию (53):

Захват трафика для заданного порта:

Захват трафика для всех портов кроме 80 и 25:

Команда netstat

Инструмент netstat используется для вывода сведений о сетевых соединениях и таблицах маршрутизации, данных о работе сетевых интерфейсов, о masquerade-соединениях, об элементах групп многоадресной рассылки. Эта утилита является, как и ifconfig , частью пакета net-tools . В новом пакете iproute2 для достижения тех же целей используется утилита ss .

Если в вашей системе netstat отсутствует, установить эту программу можно так:

Ей, в основном, пользуются, вызывая без параметров:

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

Можно вызывать netstat и с несколькими параметрами, перечислив их друг за другом:

Для вывода сведений обо всех портах и соединениях, вне зависимости от их состояния и от используемого протокола, применяется такая конструкция:

Для вывода сведений обо всех TCP-портах применяется такой вариант команды:

Если нужны данные по UDP-портам — утилиту вызывают так:

Список портов любых протоколов, ожидающих соединений, можно вывести так:

Список TCP-портов, ожидающих соединений, выводится так:

Так выводят список UDP-портов, ожидающих соединений:

А так — список UNIX-портов, ожидающих соединений:

Вот — команда для вывода статистических сведений по всем портам вне зависимости от протокола:

Так выводятся статистические сведения по TCP-портам:

Для просмотра списка TCP-соединений с указанием PID/имён программ используется такая команда:

Для того чтобы найти процесс, который использует порт с заданным номером, можно поступить так:

Команда nslookup

Команда nslookup используется для интерактивного «общения» с серверами доменных имён, находящимися в интернете. Она применяется для выполнения DNS-запросов и получения сведений о доменных именах или IP-адресах, а так же — для получения любых других специальных DNS-записей.

Рассмотрим распространённые примеры использования этой команды.

Получение A-записи домена:

Просмотр NS-записей домена:

Выяснение сведений о MX-записях, в которых указаны имена серверов, ответственных за работу с электронной почтой:

Обнаружение всех доступных DNS-записей домена:

Проверка A-записи для выяснения IP-адресов домена — это распространённая практика, но иногда нужно проверить то, имеет ли IP-адрес отношение к некоему домену. Для этого нужно выполнить обратный просмотр DNS:

Команда ping

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

В данном случае работу команды ping можно остановить, воспользовавшись сочетанием клавиш CTRL+C . В противном случае она будет выполнять запросы до тех пор, пока её не остановят. После каждой ping-сессии выводятся сводные данные, содержащие следующие сведения:

Min — минимальное время, которое требуется на получение ответа от пингуемого хоста.
Avg — среднее время, которое требуется на получение ответа.
Max — максимальное время, которое требуется на получение ответа.

Обычно, если запустить команду ping в её простом виде, не передавая ей дополнительные параметры, Linux будет пинговать интересующий пользователя хост без ограничений по времени. Если нужно изначально ограничить количество ICMP-запросов, например — до 10, команду ping надо запустить так:

А для того чтобы увидеть лишь итоговый отчёт работы ping — можно воспользоваться ключом -q :

В системах с несколькими сетевыми интерфейсами можно задавать конкретный интерфейс, которым должна пользоваться команда ping . Например, есть компьютер, имеющий интерфейсы eth0 и eth1 . Если нужно, чтобы команда ping использовала бы интерфейс eth0 — надо запустить её так:

Или можно указать адрес интерфейса. В данном случае речь идёт об IP-адресе 10.233.201.45:

Применяя эту команду, можно указать и то, какую версию протокола IP использовать — v4 или v6:

▍ Destination Host Unreachable

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

▍ Request timed out

▍ Unknown host/Ping Request Could Not Find Host

Такой результат может указывать на то, что неправильно введено имя хоста, или хоста с таким именем в сети просто не существует.

О хорошем качестве связи между исследуемыми системами говорит уровень потери пакетов в 0%, а так же — низкое значение времени получения ответа. При этом в каждом конкретном случае время получения ответа варьируется, так как оно зависит от разных параметров сети. В частности — от того, какая среда передачи данных используется в конкретной сети (витая пара, оптоволокно, радиоволны).

Итоги

Надеемся, вам пригодятся команды и примеры их использования, о которых мы сегодня рассказали. А если они вам и правда пригодились — возможно, вам будет интересно почитать продолжение этого материала.

Linux поддерживает множество видов туннелей. Это запутывает новичков, которым бывает сложно разобраться в различиях технологий, и понять то, каким туннелем лучше воспользоваться в конкретной ситуации. В материале, перевод которого мы сегодня публикуем, будет дан краткий обзор часто используемых туннельных интерфейсов ядра Linux. Сильно углубляться в эту тему мы не будем, рассмотрев лишь общие особенности туннелей и варианты их использования в Linux.

Автор этого материала полагает, что то, о чём пойдёт здесь речь, может быть интересно всем, кто имеет какое-то отношение к управлению компьютерными сетями. Список туннельных интерфейсов, а также справочные сведения о конкретной конфигурации можно получить с помощью iproute2-команды ip link help .

Здесь будут рассмотрены следующие часто используемые интерфейсы: IPIP, SIT, ip6tnl, VTI и VTI6, GRE и GRETAP, GRE6 и GRE6TAP, FOU, GUE, GENEVE, ERSPAN и IP6ERSPAN.

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

Туннель IPIP, как можно понять из его названия — это туннель, работающий в режиме «IP over IP» (RFC 2003). Заголовок пакета туннеля IPIP выглядит так, как показано ниже.

Заголовок пакета туннеля IPIP

Такие туннели обычно используются для соединения двух внутренних IPv4-подсетей через общедоступную IPv4-сеть (интернет). Применение IPIP создаёт минимальную дополнительную нагрузку на систему, но по такому туннелю можно выполнять только однонаправленную передачу данных (unicast). То есть, построив подобный туннель, нельзя будет использовать его для групповой передачи данных (multicast).

IPIP-туннели поддерживают режимы «IP over IP» и «MPLS over IP».

Обратите внимание на то, что когда загружен модуль ipip , или когда впервые создано IPIP-устройство, ядро Linux создаст в каждом пространстве имён устройство по умолчанию tunl0 с атрибутами local=any и remote=any . Получая IPIP-пакеты, ядро, в определённых случаях, будет перенаправлять их на tunl0 как на устройство, используемое по умолчанию. Это происходит тогда, когда ядро не может найти другого устройства, атрибуты local/remote которого более точно соответствуют адресам источника и приёмника пакетов.

Вот как создать IPIP-туннель:

Обратите внимание на то, что при использовании этой конфигурации её нужно привести в соответствие с реальными данными. В частности, LOCAL_IPv4_ADDR , REMOTE_IPv4_ADDR , INTERNAL_IPV4_ADDR и REMOTE_INTERNAL_SUBNET нужно заменить на адреса, используемые в вашем окружении. То же самое справедливо и для других примеров конфигураций, которые мы будем рассматривать далее.

SIT (Simple Internet Transition) — это технология создания туннелей, главной целью существования которой является соединение изолированных IPv6-сетей через интернет с использованием протокола IPv4.

Изначально технология SIT могла работать лишь в режиме туннелирования «IPv6 over IPv4». Однако за годы развития она приобрела поддержку ещё нескольких режимов. В частности, это ipip (то же самое было с IPIP-туннелем), ip6ip , mplsip и any .

Режим any используется для работы с IP- и IPv6-трафиком, что может оказаться полезным в некоторых ситуациях. SIT-туннели также поддерживают ISATAP. Вот пример использования этой технологии.

Заголовок SIT-пакета выглядит так, как показано ниже.

Заголовок пакета туннеля SIT

Когда загружается модуль sit , ядро Linux создаёт устройство по умолчанию sit0 .

Вот как создать SIT-туннель (эти действия надо выполнить на серверах A и B):

Ip6tnl

Интерфейс ip6tnl работает в режиме «IPv4/IPv6 over IPv6». Он похож на IPv6-версию туннеля SIT. Вот как выглядит заголовок пакета ip6tnl.

Заголовок пакета туннеля ip6tnl

Туннели ip6tnl поддерживают режимы ip6ip6 , ipip6 и any . Режим ipip6 представлен схемой «IPv4 over IPv6», режим ip6ip6 — это «IPv6 over IPv6». Режим any поддерживает обе схемы.

Когда загружается модуль ip6tnl , ядро Linux создаёт устройство по умолчанию с именем ip6tnl0 .

Вот как создать туннель ip6tnl:

VTI и VTI6

Интерфейс VTI (Virtual Tunnel Interface) в Linux похож на интерфейс VTI Cisco и на Juniper-реализацию защищённого туннеля (st.xx).

Этот драйвер туннелирования реализует IP-инкапсуляцию, что может быть использовано с xfrm для создания защищённых туннелей и для последующего использования поверх таких туннелей маршрутизации уровня ядра.

В целом, VTI-туннели работают почти так же как туннели IPIP или SIT. Исключением является то, что они задействуют fwmark и инкапсуляцию/декапсуляцию IPsec.

VTI6 — это IPv6-эквивалент VTI.

Вот как создать VTI-туннель:

Кроме того, конфигурировать IPsec можно с помощью libreswan или strongSwan.

GRE и GRETAP

Технология GRE (Generic Routing Encapsulation) описана в RFC 2784. При GRE-туннелировании между заголовками внутреннего и внешнего IP-пакета добавляется дополнительный заголовок GRE.

Теоретически, GRE может инкапсулировать пакеты любого протокола 3 уровня с допустимым Ethernet-типом. Это отличает технологию GRE от технологии IPIP, которая поддерживает лишь инкапсуляцию IP-пакетов. Вот как выглядит заголовок пакета при использовании технологии GRE.

Заголовок пакета туннеля GRE

Обратите внимание на то, что туннели GRE позволяют выполнять групповую передачу данных и поддерживают IPv6.

При загрузке модуля gre ядро Linux создаёт устройство по умолчанию gre0 .

В то время как туннели GRE работают на 3 уровне модели OSI, туннели GRETAP работают на 2 уровне OSI. Это означает, что одними из внутренних заголовков соответствующих пакетов являются Ethernet-заголовки.

Заголовок пакета туннеля GRETAP

Вот как создать туннель GRETAP:

GRE6 и GRE6TAP

GRE6 — это IPv6-эквивалент GRE. Туннели GRE6 позволяют инкапсулировать любые протоколы 3 уровня в IPv6. Вот как выглядит заголовок пакета GRE6.

Заголовок пакета туннеля GRE6

В туннелях GRE6TAP, как и в туннелях GRETAP, среди внутренних заголовков пакета есть и Ethernet-заголовки.

Заголовок пакета туннеля GRE6TAP

Туннелирование может выполняться на разных уровнях сетевого стека. Туннели IPIP, SIT и GRE существуют на уровне IP. А туннели FOU (они устроены по схеме «foo over UDP») работают на уровне UDP.

В применении UDP-туннелирования есть некоторые преимущества перед IP-туннелированием. Дело в том, что протокол UDP работает с существующей аппаратной инфраструктурой.

Например, это RSS в сетевых картах, ECMP в коммутаторах, это технологии расчёта контрольных сумм без участия центрального процессора. Применение соответствующего FOU-патча для разработчиков показывает значительное увеличение производительности для протоколов SIT и IPIP.

В настоящее время FOU-туннели поддерживают инкапсуляцию протоколов на основе IPIP, SIT и GRE. Вот как может выглядеть заголовок FOU-пакета.

Заголовок пакета туннеля FOU

Вот как создать туннель FOU:

Первая команда настраивает принимающий порт FOU для IPIP, привязанный к номеру 5555. Для использования GRE нужно использовать ipproto 47 . Вторая команда настраивает новый виртуальный интерфейс IPIP ( tun1 ), рассчитанный на FOU-инкапсуляцию, целевым портом которого является 5555.

Обратите внимание на то, что FOU-туннели не поддерживаются в Red Hat Enterprise Linux.

Ещё одна разновидность UDP-туннелирования представлена технологией GUE (Generic UDP Encapsulation). Разница между FOU и GUE заключается в том, что у GUE имеется собственный заголовок, который содержит сведения о протоколе и другие данные.

В настоящее время туннели GUE поддерживают внутреннюю инкапсуляцию IPIP, SIT и GRE. Вот как может выглядеть заголовок GUE-пакета.

Заголовок пакета туннеля GUE

Вот как создать GUE-туннель:

Благодаря этим командам будет создан принимающий GUE-порт для IPIP, привязанный к номеру 5555, и IPIP-туннель, настроенный на GUE-инкапсуляцию.

GUE-туннели не поддерживаются в Red Hat Enterprise Linux.

GENEVE

Туннели GENEVE (Generic Network Virtualization Encapsulation) поддерживают все возможности XLAN, NVGRE и STT. Технология GENEVE спроектирована с учётом обхода выявленных ограничений этих трёх технологий. Многие считают, что данная технология способна, в перспективе, полностью заменить эти три более старых формата. Вот как выглядит заголовок пакета туннеля GENEVE.

Заголовок пакета туннеля GENEVE

Этот заголовок похож на заголовок VXLAN-пакета. Основное различие между ними заключается в том, что заголовок GENEVE является более гибким. Он позволяет очень легко реализовывать новые возможности путём расширения заголовков с помощью полей Type-Length-Value (TLV).

Подробности о GENEVE можно узнать здесь и здесь.

GENEVE используется в SDN-решении Open Virtual Network (OVN) как стандартное средство инкапсуляции. Вот как создать туннель GENEVE:

ERSPAN и IP6ERSPAN

Технология ERSPAN (Encapsulated Remote Switched Port Analyzer) использует GRE-инкапсуляцию для расширения базовых возможностей по зеркалированию портов со 2 уровня до 3 уровня. Это позволяет пересылать зеркалируемый трафик по маршрутизируемой IP-сети. Вот как выглядит заголовок пакета ERSPAN.

Заголовок пакета туннеля ERSPAN

Туннели ERSPAN позволяют Linux-хостам действовать в роли источника трафика ERSPAN и отправлять отзеркалированный ERSPAN-трафик либо на удалённый хост, либо в некий пункт назначения ERSPAN, который принимает и обрабатывает ERSPAN-пакеты, сгенерированные коммутаторами Cisco или другими устройствами, поддерживающими ERSPAN. Подобную систему можно использовать для анализа и диагностики сети, для выявления вредоносного трафика.

Linux в настоящее время поддерживает большинство возможностей двух версий ERSPAN — v1 (type II) и v2 (type III).

Вот как создавать ERSPAN-туннели:

Ещё можно поступить так:

Добавим tc-фильтр для мониторинга трафика:

Итоги

Мы рассмотрели здесь довольно много технологий создания туннелей в Linux. Вот сводная таблица по ним.

Тип туннеля / подключения	Внешний заголовок	Инкапсулированный заголовок	Внутренний заголовок
ipip	IPv4	None	IPv4
sit	IPv4	None	IPv4/IPv6
ip6tnl	IPv4	None	IPv4/IPv6
vti	IPv4	IPsec	IPv4
vti6	IPv6	IPsec	IPv6
gre	IPv4	GRE	IPv4/IPv6
gretap	IPv4	GRE	Ether + IPv4/IPv6
gre6	IPv6	GRE	IPv4/IPv6
gre6tap	IPv6	GRE	Ether + IPv4/IPv6
fou	IPv4/IPv6	UDP	IPv4/IPv6/GRE
gue	IPv4/IPv6	UDP + GUE	IPv4/IPv6/GRE
geneve	IPv4/IPv6	UDP + Geneve	Ether + IPv4/IPv6
erspan	IPv4	GRE + ERSPAN	IPv4/IPv6
ip6erspan	IPv6	GRE + ERSPAN	IPv4/IPv6

Обратите внимание на то, что все туннели, примеры создания которых здесь показаны, существуют только до перезагрузки сервера. Если вы хотите создать туннель, восстанавливающийся и после перезагрузки, рассмотрите возможность использования демона для настройки сети, наподобие NetworkManager, или примените подходящий механизм из используемого вами дистрибутива Linux.

Развивая IT-инфраструктуру рано или поздно приходит задача интегрироваться с какими-либо сервисами крупной организации. Это может быть, например, банк или оператор связи. Как правило в крупных организациях действуют устоявшиеся политики информационной безопасности, которые в частности требуют реализации сервиса с внешней по отношению к ним инфраструктурой через шифрованные каналы — IPSec. В то же время в небольших организациях ~~стартапах~~ нет опыта организации таких схем, а из оборудования есть только VDS с Linuxом на борту. Более того, к моему удивлению, в рунете практически нет материалов с описанием инструментов траблшутинга под Linux. Попробуем устранить этот пробел и описать практическую часть настроек.

Общая схема сервиса представлена ниже. Как правило, в крупных организациях все уже стандартизировано, поставлено на поток, всякие возможные шифрования и прочие сетевые штуки делаются на отдельном оборудовании (циски-джуниперы и иже с ними), и, что важнее, отдельными людьми (возможно каждый синий квадратик на схеме ниже обслуживают разные люди). У вас же одна виртуалка, с которой будет и запускаться сервис, и организовываться IPSec.

Обратите внимание, сам IPSec организовывается между одними IP-адресами (в моем примере 10.0.255.1 <-> 10.0.1.1 ), а сам сервис — между другими ( 192.168.255.1<-> 192.168.1.1 ). Такие схемы еще называются IPSec Network-Network.

Простой пример — вы работаете в молодой, но очень амбициозной компании СуперСервис, и вам надо организовать взаимодействие с закрытым API компании МегаТелеком. Ваша инфраструктура — один сервер VDS, инфраструктура партнера — куча сетевого и серверного оборудования. Задача делится на два этапа:

Организовать транспорт (как будет происходить межсетевое взаимодействие).
Настроить сервис (запустить приложения непосредственно на серверах).

Концепция IPSec

Далее я приведу немного теории для людей, совсем не знакомых с технологией. Все, что я дальше опишу, относится к чистому Ethernet и IPv4. Я не буду вдаваться в алгоритмы шифрования, обмена ключами, вместо этого сосредоточусь на сетевой части.

IPSec — набор техник и протоколов по организации защищенного соединения.

В отличии от прочих технологий туннелирования (GRE, PPP, L2TP, даже MPLS-TE) для IPSec не создается явных туннельных интерфейсов, через которые можно маршрутизировать трафик. Вместо этого в IPSec предусмотрена концепция так называемых Security Assotiations (SA). SA и есть туннель от одного сетевого устройства к другому. Но не стоит забывать, что SA — не сетевой интерфейс в нормальном понимании этого слова, классическая маршрутизация здесь не работает. Вместо таблицы маршрутизации здесь работает концепция Security Policy (SP). Мы явно прописываем что-то типа аксес-листа (ACL) для пропуска трафика через определенную SA. Все эти вещи определены в так называемом фреймворке ISAKMP.

ISAKMP — описание процедур IPSec, в литературе называют его фреймворком. В нем описываются термины SA, SP, SAD (Security Assotiations Database), SPD (Security Policy Database), необходимость установки вспомогательных туннелей… ISAKMP построен так, чтобы не зависеть от технологий туннелирования, алгоритмов аутентификации и шифрования. Он просто вводит необходимые определения.

IKE(v1/2) — непосредственно протокол аутентифиации. Он уже реализовывает алгоритмы обмена ключами и их применение.

Благодаря концепции Cisco сейчас ISAKMP и IKE считаются синонимами.

Перед шифрованием трафика стороны должны договориться о параметрах (и ключах) этого шифрования. Для этого между обоими сторонами поднимается вспомогательный туннель (его еще называют ISAKMP туннель), который действует все время. Туннель этот двунаправленный, представляет из себя соединение по UDP (по умолчанию на порту 500). Для организации этого вспомогательного туннеля стороны должны проверить подлинность друг друга (должен совпасть пароль). Этим занимается протокол IKEv1/2 (Internet Key Exchange). И уже по организованному ISAKMP туннелю стороны договариваются о шифровании непосредственно пользовательского трафика.

Собственно организация IPSecа делится на две фазы:

Создание вспомогательного туннеля ISAKMP
Создание туннеля пользовательских данных

Первая фаза (организация ISAKMP SA) может осуществляться в двух режимах:

Во всех способах шифрования в оригинальный IP-пакет добавляются дополнительные заголовки, происходит инкапсуляция. Существует два способа этой инкапсуляции — AH (Authentication Header) и ESP (Encapsulation Security Payload). AH только аутентифицирует пакет (подписывает цифровой подписью отправителя), ESP и аутентифицирует (подписывает), и шифрует. На сегодняшний день AH уже практически не используется, все упаковывают в ESP.

Шифровать и аутентифицировать исходный IP-пакет можно без учета IP-заголовка (транспортный режим) или вместе с ним (туннельный режим). Транспортный используется тогда, когда планируется организовать свои туннели по другим технологиям (не IPSec/ESP). Например, GRE, l2tp, ppp. Для целей подключения какого-то сервиса ко внутренней инфраструктуре большой организации практически не используется. Я использовал такой сценарий для объединения нескольких офисов в один VPN через IPSec-и. Нам же более интересен туннельный режим. Как видно из картинки, здесь добавляется один дополнительный IP-заголовок.

Кстати, есть реальный пример использования AH-инкапсуляции. Предположим, у нас есть две сети, подключенные к разным маршрутизаторам. Хосты должны передавать информацию с MTU 1500 байт без фрагментации, но у нас есть промежуточный участок, который поддерживает только 1380 байт. Вся трасса доверенная. Мы можем воспользоваться тем, что IPSec не создает туннельных интерфейсов, в классическом смысле через которые трафик не маршрутизируется. Мы создадим SA туннель AH типа (нам же не надо шифровать), тогда трафик пойдет него. В трафике фрагментироваться будут только внешние IP-пакеты (по внешним IP-заголовкам), внутренние будут пересобираться без изменений.

Обратите внимание, что заголовок ESP встает до транспортных TCP/UDP. Помните, в заголовке IP-пакета есть поле Protocol? На основе этого поля сетевое оборудование (да и конечные хосты) корректно обрабатывают IP-пакеты. Так вот для ESP свой номер — 50. Полный список протоколов для этого поля можно посмотреть на вики, бывает весьма полезно.

Отсутствие заголовка транспортного уровня (TCP/UDP/ICMP уже зашифрованы!) накладывает ограничение на технологии типа NAT. Вспомните, NAT с трансляцией портов (overload, PAT, MASQARADE, у него много имен) работает на основе портов транспортных протоколов. А в зашифрованном туннеле IPSec их нет! Для преодоления этой проблемы есть такая технология, как IPSec NAT-Traversal (NAT-T). В ходе первой фазы стороны согласовывают возможность использовать NAT-T. Если обе стороны поддерживают NAT-T (да еще и на одинаковых UDP-портах), тогда в итоговых туннелях для трафика добавляется заголовок UDP, с которым пакеты уже пройдут через маршрутизаторы с трансляцией сетевых адресов.

Политики состоят из адреса источника, адреса назначения, направления (in, out, fwd) и параметров пользовательских туннелей (здесь как раз описываются ESP это будет или AH, туннельный вариант или транспортный). Это больше похоже на организацию правил для NATа. NATу тоже недостаточно записей таблицы маршрутизации. И там тоже указываются правила откуда, куда и как, а не куда и через что. И также неверным движением руки можно завалить всю связь на удаленном сервере.

Все манипуляции с IPSec добавляют заголовки служебной информации. Минимум они съедят еще 40 байт от исходного пакета. Таким образом, например, при стандартном MTU для PPPoE в 1380 байт соединений реальное MTU будет < 1340.

IPSec в Linux

Займемся практикой на примере DEB-дистрибутивов. Я буду рассматривать только случай с авторизацией на основе pre-shared-key (PSK), будем настраивать схему из начала статьи.

Сам по себе IPSec поддерживается ядром, но поддержка эта весьма ограничена. В действительности ядреные модули занимаются только тем, что связано с шифрованием и уже полученными (переданными в ядро) ключами — обработка пакетов. А чтобы передать туда параметры и правила, с которыми нужно обрабатывать трафик, требуется отдельное программное обеспечение. В качестве такого софта есть несколько решений:

KAME, перекочевавший из BSD
xSWAN (strongswan, freeswan, libreswan, etc)

Традиционно KAME состоял из двух компонент

Демона racoon для управления туннелем ISAKMP.
Утилиты setkey для управления SA-туннелей с данными.

Как всегда, подробности в man 5 racoon.conf

Дальше займемся утилитой setkey. Она тоже запускается как демон ( /etc/init.d/setkey <start|stop|restart> ), но по факту она выполняет скрипт /etc/ipsec-tools.conf . Как я и говорил, она уже задает создает туннели для пользовательского трафика. А именно задает SA и SP для них. Это что-то вроде crypto-map на ASA. Самый простой вариант для нас — добавить просто SP. Тогда SA построится автоматически исходя из параметров второй фазы, указанной в настройках racoon.

Но есть возможность вообще не использовать параметры второй фазы из racoon, а задать SA через эту утилиту. Подробности и синтаксис можно посмотреть в man 8 setkey . А я же приведу приведу пример простейшей конфигурации.

На текущий момент утилиту setkey дублирует модуль iproute2.
В рамках него есть две команды управления записями SA и SP.

ip xfrm state
ip xfrm policy

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

Статический маршрут без определения некстхопа, но с явным указанием исходящего интерфейса и IP-адреса.
Задание маршрутов на основе policy based routing (PBR в Linux ака ip rule).
Трансляция адресов (NAT/MASQARADE).

Мы можем добавить на наш интерфейс дополнительный (secondary) IP-адрес, при этом лучше сделать alias для этого интерфейса
root@localhost:

Проверка работоспособности

Не забывайте, туннель поднимется только тогда, когда в него пойдет трафик! Надо запустить пинг с конкретного интерфейса (IP-адреса) до назначения.
root@localhost:

Мы можем увидеть, поднялся ли ISAKMP-туннель

Также мы можем посмотреть туннели с пользовательскими данными

Бывает полезно в tcpdump посмотреть логику установления соединения. Здесь можно также увидеть фазы установления соединения и уже передаваемый шифрованный в ESP трафик. Конечно есть техники его расшифровки, но обычно такого вывода уже достаточно.

При удаленном подключении по SSH, чтобы не плодить кучу окон удобно запускать tcpdump в фоне:

Запускаем ping, telnet, netcat…

Также в логах можно увидеть успешный статус установления соединения. В нем видно успешное установление обоих фаз IPSec.

Вот и все. Остается добавить все необходимые манипуляции в автозагрузку, и можно начинать интеграцию приложений.

Читайте также: