Чи потрібен IPsec маршрутизатору між двома партнерами IPsec?

Лабораторна вправа, яка каже «налаштуйте IPsec між двома майданчиками», приховує дві різні задачі. Дві кінцеві точки завершують тунель: вони ведуть переговори, автентифікують, шифрують і розшифровують. Будь-який маршрутизатор між ними пересилає пакети, зовнішній заголовок яких належить кінцевим точкам, і робить це, не знаючи, що тунель існує.

Визначити, яка задача ставиться перед пристроєм, — це перший крок вправи. Більша частина плутанини в лабораторних звітах і значна частка плутанини у виробничих схемах походить від того, що «підтримує IPsec» трактується як одна властивість замість двох.

Пересилання — це не завершення

У тунельному режимі зовнішній IP-заголовок адресований пристроям, що завершують тунель. Маршрутизатор посередині шукає призначення і пересилає, точно як для будь-якого іншого пакета, а корисне навантаження, яке він несе, для нього непрозоре.

Ця непрозорість навмисна. Маршрутизатор не зберігає секрет партнера, не веде переговорів і не потребує бази політик. Йому потрібен маршрут до далекої кінцевої точки та дозвіл переслати пакет.

Змішування обох речей призводить до реальних помилок: просити транзитний міжмережевий екран «дозволити IPsec», коли фактична вимога — дозволити протокол 50 між конкретними адресами, або очікувати, що проміжний пристрій розшифрує для перевірки, коли в нього немає ключа.

Що проміжний пристрій все ж має зробити правильно

Пересилання має свої вимоги. Маршрути мають досягати обох зовнішніх кінцевих точок, і будь-яка політика на шляху має дозволяти реальний зовнішній трафік, а не припущений номер порту. Правило, написане проти TCP 443, бо хтось припустив TLS, не збіжиться з протоколом 50.

Власний ESP — це IP-протокол 50. Це не TCP 50 і не UDP 50, і правило, що блокує трафік, який не є TCP, відкине його. Якщо проєкт використовує інкапсуляцію UDP, видимий транспорт змінюється на порт інкапсуляції, і політика має відповідати обраному проєкту.

Має значення й розмір пакета. Маршрут, що несе малий зонд, не доводить, що весь інкапсульований обмін уміщується. Шлях, який відкидає великі пакети, може дозволити переговорам вдатися, а робочому навантаженню — ні, і це виглядає як проблема застосунку. Тестуйте трафіком розміру реального робочого навантаження, перш ніж звинувачувати тунель.

Чому симулятор змінює питання

Симулятор — це не маршрутизатор із коротшим списком функцій; це модель із документованою підмножиною та власними правилами про те, що даний пристрій можна налаштувати робити. FAQ Cisco Packet Tracer прямо зазначає, що пристрої та протоколи — спрощені моделі.

Так питання стає трьома питаннями. Чи пересилає симульований пристрій пакети, потрібні сценарію? Чи пропонує той самий пристрій поверхню налаштування, яку передбачає урок? І чи означає прийнята команда, що поведінка справді симулюється, чи лише аналізується?

Відсутня команда може бути обмеженням моделі, а не помилкою у вашій конфігурації. Наявна команда може прийняти синтаксис, не відтворюючи всієї виробничої поведінки. Перевірте довідку пристрою встановленої версії, перш ніж робити висновок у будь-якому напрямку.

Як написати умову успіху для лабораторії

Для уроку про underlay умова успіху — доступність кінцевих точок плюс зовнішні пакети, що проходять через проміжний пристрій. Доведіть це лічильниками самого симулятора або переглядом пакетів і назвіть протокол, який очікуєте побачити.

Для уроку про IPsec додайте стан переговорів і один захищений потік від LAN до LAN. Якщо симулятор показує асоціації безпеки, запишіть їх. Якщо ні, скажіть це у звіті, замість того щоб натякати, що тунель перевірено.

Тримайте версію симулятора, вибрані пристрої та навчальну мету разом із файлом топології. Саме цей запис дає змогу комусь іншому повторити вправу й зрозуміти, які частини було змодельовано.

Виробнича конфігурація потребує власних доказів платформи. Зелений симульований пакет — це навчальний результат, а не заява про сумісність з обладнанням, яке ви розгортатимете.