AH или ESP? Решайте по тому, что пакет должен защищать
AH аутентифицирует большую часть пакета и ничего не шифрует; ESP умеет и шифровать, и аутентифицировать. Выбирайте по полям, которые нужно защитить, а затем согласуйте режим.
Два предложения IPsec могут называть один и тот же алгоритм целостности на основе SHA и при этом требовать разные протоколы защиты; AH и ESP не два написания одной настройки аутентификации. Сначала прочитайте протокол, затем его алгоритмы, затем режим, и большая часть неясности исчезает. AH аутентифицирует пакет, включая те поля заголовка IP, которые остаются неизменными в пути, а ESP аутентифицирует и шифрует то, что инкапсулирует, и оставляет внешний заголовок нетронутым. Именно эта разница определяет больше внедрений, чем любое имя хэша.
Что покрывает AH, а ESP нет
AH даёт целостность, аутентификацию источника данных и определённую им службу защиты от повторов, и никакой конфиденциальности. Его охват включает данные верхнего уровня и те поля заголовка IP, которые его правила считают неизменными, ровно ту часть, которую ESP в транспортном режиме оставляет снаружи. Когда требование говорит, что нужно аутентифицировать сам заголовок IP, AH тот протокол, который на это отвечает.
Этот охват также причина хрупкости AH на практике. Изменяемые поля, такие как TTL, контрольная сумма заголовка и некоторые параметры, нельзя аутентифицировать, потому что маршрутизаторы могут их переписывать, поэтому протокол обнуляет их перед вычислением проверки. Так что всё, что переписывает адреса, ломает вычисление, а не только политику.
NAT превращает выбор в ограничение
Трансляция адресов переписывает источник или назначение в заголовке IP, который AH только что аутентифицировал, поэтому проверка целостности не проходит на дальнем конце, причём как ошибка протокола, а не как читаемое сообщение. ESP не аутентифицирует внешний заголовок, поэтому ESP с прохождением NAT работает, а AH за NAT нет. Туннель, у которого обе стороны стоят за обычными маршрутизаторами, именно то место, где это проявляется первым. Поэтому первый вопрос не в том, какой протокол сильнее, а в том, есть ли между сторонами транслятор.
Если есть, AH отпадает, и разговор переходит к ESP и выбору его алгоритмов. Это ограничение, а не предпочтение, поэтому ему место в начале решения, а не в конце.
Режим умножает вопрос
ESP в транспортном режиме защищает полезную нагрузку верхнего уровня и не трогает заголовок IP; в туннельном режиме он инкапсулирует весь внутренний пакет, включая внутренний заголовок IP, и защищает его. У AH те же два режима, поэтому AH или ESP это на самом деле четыре комбинации до выбора любого алгоритма.
Алгоритмы ESP в комбинированном режиме затем решают целостность без второго протокола. AES-GCM и ChaCha20-Poly1305 аутентифицируют и шифруют в одной конструкции, поэтому добавление AH сверху ничего не покупает, но стоит ещё одного заголовка и ещё одних переговоров. Архитектура допускает AH и ESP вместе, и практический вопрос поддерживают ли ваш шлюз и ваша версия это сочетание и сможет ли кто-то сопровождать его потом.
Честная замена для одного AH
Вариант ESP только с целостностью сохраняет алгоритм и отказывается от заявления о шифровании вместо того, чтобы его имитировать, и проходит через NAT. Если старая схема использовала AH, потому что требовалась аутентификация без конфиденциальности, этот вариант и есть прямой перевод, а не шифрованный туннель с припиской.
Видеть ESP в предложении тоже не доказательство шифрования. Читайте алгоритм шифрования: запись NULL означает только целостность, а запись комбинированного режима и то, и другое.
Решите тремя вопросами
Спросите, нужна ли конфиденциальность, есть ли на пути транслятор и какие поля заголовка нужно аутентифицировать. Эти три ответа указывают на один протокол и один режим, и записать их быстрее, чем позже перечитывать RFC.
Затем проверьте то, что принято, а не то, что предложено. ip xfrm state показывает протокол, режим и алгоритмы установленной ассоциации, а при несовпадении не устанавливается ничего, что является более чистым сбоем, чем туннель, который поднимается без нужной защиты.
Держите сбои аутентификации, охват селекторов и ошибки маршрутизации отдельно от этого выбора. Они дают разные симптомы, и винить протокол в проблеме селектора верный способ потратить день на замену хэшей без причины.