Транспортний чи тунельний режим: вирішуйте за пакетом, а не за схемою
Транспорт і тунель описують, що міститься всередині ESP, а не те, чи задіяно хост або шлюз. Три питання визначають, який режим потрібен розгортанню.
Схеми з підручників пов’язують транспортний режим із двома хостами, а тунельний — із двома шлюзами, і це правило тримається до першого розгортання, яке його порушує. Режим описує, що обгортає пакет ESP, а не хто є сторонами. Шлюз може захищати трафік у транспортному режимі, а пара хостів може використовувати тунельний режим, якщо так вибере. Три питання визначають, що потрібно конкретному розгортанню.
Режим — це розкладка, а не топологія
У транспортному режимі заголовок ESP іде після заголовка IP і перед корисним навантаженням наступного рівня, тому початковий заголовок IP залишається зовні й видимий. У тунельному режимі захищений вміст — це цілий пакет IP, а новий зовнішній заголовок називає двох учасників IPsec.
| Mode | What follows the outer IP header | Headers a capture shows |
|---|---|---|
| Transport | ESP, then the next-layer payload | One IP header |
| Tunnel | ESP, then a whole inner IP packet | Outer and inner headers |
За обраної конфіденційності захищена область у тунельному режимі охоплює цей внутрішній заголовок IP, тому запис без ключів не може повідомити справжні кінцеві точки. Зовнішній заголовок залишається читабельним в обох випадках, і саме це взагалі уможливлює пошук несправностей.
Перше питання: що саме всередині ESP
Подивіться на пакет, який створює застосунок, і запитайте, який кордон його захищає. Якщо відповідь — корисне навантаження транспорту між двома вже правильними адресами, транспортний режим пасує без вигадування другого заголовка. Якщо захищеному вмісту потрібні власні адреси, бо справжні кінцеві точки відрізняються від сторін, що несуть трафік, роботу виконує тунельний режим. Обидва випадки існують в одній організації, тому одна заява про політику рідко охоплює все.
На це питання можна відповісти за записом і таблицею маршрутизації. На нього не можна відповісти за кресленням, яке називає блоки клієнтом і сервером. Запис, зроблений на будь-якій стороні, за секунди показує, на яку з двох ви дивитеся.
Друге питання: чи є всередині вже тунель
L2TP — це історичний контрприклад, який це показує. Служба несе PPP усередині сеансу L2TP, і IPsec захищає цей обмін; розкладка задає транспортний режим, а тунельний режим дозволено як опцію. Видимий результат — тунель на рівні служби, зовнішній захист якого використовує транспортний режим.
Отже, слово тунель в описі продукту нічого не каже про режим шару під ним. Запишіть, яке питання це вирішило, бо наступний рецензент запитає те саме. Читайте специфікацію такого поєднання, а не міркуйте від назви, бо ця звичка запобігає більшості суперечок про те, що продукт має підтримувати.
Третє питання: чого вимагає сторона
Дві сторони мають домовитися, а пропозиція, яка дає один режим, тоді як інша сторона вимагає другий, зазнає невдачі під час узгодження, а не тихо деградує. Запитайте власника далекого кінця, який режим називає політика, і перевірте пропозицію, а не стислий виклад документації.
Змішані середовища звичайні: один шлюз завершує сеанси транспортного режиму для старого продукту й сеанси тунельного режиму для зв’язку між майданчиками. Режим задається для кожної асоціації, а не для пристрою. Просіть список асоціацій, а не назву функції, бо назва подорожує швидше за конфігурацію.
Читання наявної асоціації
Для огляду перелічіть сторони, режим, селектори й протокол наступного рівня, потім додайте будь-яку інкапсуляцію, обгорнуту навколо результату. Трансляція адрес додає свій зовнішній вигляд і не є режимом; трансльований потік усе ще може бути будь-яким із двох. Список — єдиний артефакт, який показує асоціацію так, як її встановлено, а не так, як її задумано.
Завершіть питанням про маршрутизацію й авторизацію, бо правильна розкладка пакета нічого не каже про те, які підмережі дозволені або чи існує зворотний шлях. Вони живуть у політиці й у таблиці маршрутів, і жодне з них не змінює аргумент про режим.