Мониторинг на интерфейс на 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 интерфейс, а други платформи назовават и реализират еквивалентния обект по различен начин. Прочетете сравнението, базирано на маршрути, за устройството пред вас, преди да пренасяте допускания от друга реализация. Шаблон за мониторинг, който пасва на броячите на един доставчик, тихо ще подведе при друг.