IPsec ESP: что он переносит и как доказать, что трафик идёт
ESP в туннельном режиме инкапсулирует внутренний IP-пакет и определяет свою ассоциацию по SPI. Прочитайте состояние, затем посмотрите, как один поток двигает счётчики.
ESP переносит трафик в VPN на базе IPsec, и его runbook начинается с одного правила: прочитайте ассоциацию безопасности, прежде чем менять политику. Большая часть необъяснимого поведения ESP сводится к селектору, который не совпал, к режиму, который предположили, а не прочитали, или к счётчику, который никто не проверил, пока шёл один поток. Три шага ниже устанавливают, что что переносит, доказывают, что один поток это использует, и оставляют откат, который не зависит от памяти. Каждый шаг даёт одно наблюдение, которое стоит записать.
Знайте поля, прежде чем их читать
ESP ставит заголовок перед защищёнными данными и трейлер после них. Заголовок несёт индекс параметров безопасности, который определяет, какую ассоциацию должен использовать получатель, номер последовательности для обнаружения повторов и в трейлере заполнение, которое держит полезную нагрузку выровненной для шифра. Поле следующего заголовка в трейлере говорит, что представляет собой защищённое содержимое, и именно так получатель узнаёт, что он декапсулировал.
Режим меняет то, что находится внутри этой защиты. В туннельном режиме защищённый материал — это полный внутренний IP-пакет, и новый внешний заголовок переносит его между оконечными точками. В транспортном режиме защита охватывает полезную нагрузку верхнего уровня существующего пакета, поэтому второго IP-заголовка для распаковки нет. Какой режим используется — это факт конфигурации, а не вопрос толкования. Читайте его из записи состояния, а не выводите из схемы.
Ни один из режимов не скрывает внешнюю адресацию, которая должна доставить пакет. Это свойство замысла, а не недостаток, и именно поэтому промежуточный наблюдатель по-прежнему видит, какие два адреса разговаривают, даже когда полезная нагрузка непрозрачна.
Шаг первый: прочитайте состояние, затем политику
Записи состояния хранят ключи и счётчики; записи политики хранят селекторы, которые решают, чему разрешено ими пользоваться. В Linux и то и другое видно без перехвата пакетов, и чтение их в этом порядке оставляет два вопроса раздельными.
ip xfrm state
ip xfrm policyВ выводе состояния проверьте источник и назначение ассоциации, режим и то, показывает ли инкапсуляция порты UDP. Эти порты означают, что используется прохождение через NAT, что меняет то, что должен разрешить промежуточный межсетевой экран, но не то, какие селекторы или ключи действуют на оконечных точках.
Затем прочитайте селекторы в политике. Селектор, указывающий более узкий префикс, чем проверяемый трафик, — самая частая причина, по которой работающий туннель будто игнорирует поток, а селектор для неправильного протокола даёт ту же тишину.
| Field | Where it appears | What it decides |
|---|---|---|
| Security parameter index | ESP header, and the receiving state entry | Which association and keys the receiver applies |
| Sequence number | ESP header | Replay detection for that association |
| Next header | ESP trailer | What the decapsulated payload contains |
| Inner IP header | Inside tunnel-mode payload only | The original source and destination the endpoints act on |
| Traffic selectors | Policy, not the packet | Which local traffic is allowed to use the association |
Инструменты производителей выводят ту же информацию в более удобной форме. ipsec statusall в strongSwan перечисляет дочерние ассоциации, их селекторы и счётчики байтов, что часто быстрее, чем читать сырой вывод xfrm, когда вы уже знаете, на какую дочернюю ассоциацию смотреть.
Шаг второй: докажите, что один поток двигает счётчики
Счётчики имеют смысл, только если вы знаете, что должно было их сдвинуть, поэтому выберите источник и назначение, которые селектор точно покрывает, и отправьте один безобидный запрос. Затем прочитайте ту же запись ещё раз и сравните.
ip -s xfrm state
tcpdump -ni any espДва чтения рассказывают разные истории. Пакеты, которые растут на исходящей стороне, но никогда на входящей, указывают на проблему пересылки или обратного пути, а не ключа, потому что пакет был инкапсулирован и ушёл. Если не двигается ни один счётчик, трафик ни разу не совпал с политикой, и селектор — то место, где нужно смотреть.
Перехват на том же шаге подтверждает инкапсуляцию на проводе, включая то, являются ли внешние пакеты ESP или ESP с инкапсуляцией в UDP. Он также показывает адреса, которые действительно несли поток, и они иногда отличаются от тех, что были в конфигурации, которую вы читали.
Шаг третий: измените одну вещь и сохраните откат
Запишите источник, назначение, режим, селекторы и счётчики ассоциации, прежде чем что-либо менять. Если изменение ухудшит положение, именно эта запись позволит восстановить предыдущее состояние, а не собирать работающую конфигурацию заново из догадки. Запись занимает минуту и экономит час позже. Это ещё и единственный артефакт, который переживает человека, сделавшего изменение.
Измените один селектор или один параметр, перезагрузите его и повторите второй шаг на том же потоке. Удаление ассоциации разрушает каждый использующий её поток, поэтому точечная правка и перезагрузка дочерней ассоциации почти всегда лучше, чем очистка состояния ради того, чтобы увидеть, что произойдёт.
Откат правки селектора — это восстановление прежней политики и её перезагрузка, с оговоркой, что партнёру может понадобиться соответствующее изменение, если селектор согласуется, а не является локальным. Запишите эту зависимость, пока она свежа, потому что наполовину восстановленную пару сложнее осмыслить, чем любое из двух конечных состояний.
Наконец, держите границы честными. Работающая ассоциация ESP доказывает, что два шлюза защищают и доставляют сегмент, и ничего не говорит о том, аутентифицирует ли приложение сверху своих пользователей или шифрует то, что хранит. Это отдельные меры контроля с отдельными доказательствами, и runbook закончен только тогда, когда следующий человек может повторить его по заметкам.