ідправника і запобігти модифікацію пакета при транспортуванні. Але на відміну від транспортного режиму, тут инкапсулируется весь IP пакет, а це дозволяє адресами відправника і одержувача відрізнятися від адрес, що містяться в пакеті, що дозволяє формувати тунель. Коли пакет тунельного режиму приходить адресату, він проходить ту ж аутентифікаційні перевірку, що і пакет AH-типу, після чого видаляються заголовки IP і AH і відновлюється первісний формат пакета.
Більшість реалізацій розглядає оконечную точку тунелю в якості мережного інтерфейсу. Реконструйований пакет може бути доставлений локальній машині або маршрутізован куди-небудь ще (згідно IP-адресою місця призначення в Інкапсульована пакеті). Подальша його транспортування вже не забезпечується засобами безпеки IPsec.
У той час як транспортний режим використовується виключно для забезпечення безпечної зв'язку між двома комп'ютерами, тунельний режим зазвичай застосовується між шлюзами (маршрутизаторами, мережевими екранами, або окремими VPN пристроями) для побудови VPN (Virtual Private Network).
Слід зауважити, що в пакеті IPsec немає спеціального поля режим raquo ;: яке б дозволяло розділити транспортний режим від тунельного, цю функцію виконує поле наступний заголовок пакета AH.
Коли поле наступний заголовок відповідає IP, це означає, що пакет інкапсулює всю IP-дейтограмму (тунельний режим), включаючи незалежні адреси відправника та одержувача, які дозволяють реалізувати маршрутизацію після тунелю. Будь-яке інше значення поля (TCP, UDP, ICMP і т.д.) означає транспортний режим (безпечне транспортування за схемою точка-точка). IP дейтограмма верхнього рівня має ту ж структуру незалежно від режиму, і проміжні маршрутизатори обробляють трафік, не аналізуючи внутрішній зміст IPsec/AH. Зауважимо, що ЕОМ, на відміну від мережевого шлюзу, повинна підтримувати як транспортний, так і тунельний режим, але при формуванні з'єднання машина-машина формування тунелю представляється надлишковим. Крім того, для мережевого шлюзу (маршрутизатора, мережевого екрану і т.д.) необхідно підтримувати тунельний режим, в той же час підтримка транспортного режиму представляється корисною лише для випадку, коли шлюз сам є кінцевим адресатом (наприклад, у разі реалізації процедур віддаленого управління мережею). AH містить ICV (Integrity Check Value) в аутентификационной частині заголовка, і ця контрольна сума формується звичайно (але не завжди) за допомогою стандартного криптографічного хеш алгоритму, наприклад, MD5 або SHA - 1. Тут використовується не традиційна контрольна сума, яка не може запобігти навмисне спотворення вмісту, а алгоритм HMAC (Hashed Message Authentication Code), який при обчисленні ICV застосовує секретний ключ. Незважаючи на те, що хакер може заново обчислити хеш, без секретного ключа він не зможе коректно сформувати ICV. Алгоритм HMAC описаний у документі RFC 2104. Зауважимо, що IPsec/AH не визначає, якою має бути аутентификационной функція, замість цього надаються рамки, в яких можна реалізувати будь-яку функцію, узгоджену відправником та одержувачем. Можна використовувати для аутентифікації цифровий підпис або криптографічний функцію, якщо обидва учасники їх підтримують. Саме тому, що AH забезпечує гарний захист вмісту пакета, тому що цей протокол покриває все, що тільки потрібно захистити, цей захист призводить до несумісності з NAT (Network Address Translation).
Протокол NAT використовується для встановлення відповідності між приватними IP-адресами (наприклад, 19.125.1 X) і легальними IP. При цьому IP заголовок модифікується пристроєм NAT шляхом заміни IP-адрес відправника і одержувача. Коли змінюються IP-адреси, потрібно заново обчислити контрольну суму заголовка. Це потрібно зробити в будь-якому випадку. Оскільки пристрій NAT зазвичай розміщується в одному кроці між відправником та одержувачем це вимагає, крім того декрементаціі значення TTL (Time To Live). Так як поля TTL і контрольна сума заголовка завжди модифікуються на прольоті, AH знає, що ці поля слід виключити із зони захисту, але це не стосується IP адрес. Адреси включені в область обчислення ICV, і будь-яка модифікація викличе збій при перевірці ICV одержувачем. Так як обчислення ICV вимагає знання секретного ключа, який невідомий проміжним вузлам, маршрутизатор NAT не зможе заново обчислити ICV.
Аналогічна проблема виникає при використанні протоколу PAT (Port Address Translation), який встановлює відповідність кількох приватних IP адрес одному зовнішньому IP. У цьому випадку змінюються не тільки IP-адреси. Але й коди портів в UDP і TCP пакетах (а іноді і в полі даних). Це вимагає багато більшою адаптивності з боку пристрою NAT, і більш серйозних модифікацій всій IP дейтограмми. З цієї причини, протокол AH в тунельному або транспортному режимі повністю несумісний з NAT. Зауважимо, що ця трудність не відноситься д...
