Моніторинг інтерфейсу тунелю IPsec: що читати

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

Пройдіть їх по черзі й зупиніться на першому, який не проходить.

Що інтерфейс додає до картини

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

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

Прочитайте чотири стани, перш ніж звинувачувати тунель

Почніть з інтерфейсу й маршруту, потім з асоціації, потім із застосунку. Кожен має власну команду й власний підпис відмови. Чистий результат на одному рівні не є чистим результатом на наступному. Виконайте всі чотири, перш ніж робити висновок. Один зелений рядок рідко щось вирішує.

ip -s link show xfrm0
ip route get 10.20.30.40
ip xfrm state
ip xfrm policy
swanctl --list-sas
tcpdump -ni xfrm0 -c 20 host 10.20.30.40

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

Тест застосунку йде останнім і навмисно: успішний ping на протилежний бік тунелю не доводить, що служба за ним приймає з’єднання.

Порівняйте внутрішні лічильники із зовнішніми

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

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

Якщо внутрішні лічильники зростають, а зовнішні ні, відсутнім кроком зазвичай є маршрут або політика, що надсилає пакети в тунель, а не сам тунель.

Спостерігайте це під час перевипуску ключів і відмови

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

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

strongSwan документує власну модель інтерфейсу XFRM, а інші платформи називають і реалізують еквівалентний об’єкт інакше. Прочитайте порівняння на основі маршрутів для пристрою перед вами, перш ніж переносити припущення з іншої реалізації. Шаблон моніторингу, що пасує до лічильників одного постачальника, непомітно введе в оману на іншому.