Откриването на мъртъв партньор в IKEv2 не проверява приложението ви

Проверката за живот в IKEv2 задава един въпрос: отговаря ли все още другият партньор по защитената контролна връзка. Тя не измерва дали вътрешно приложение е здраво, дали има маршрут зад шлюза и дали разглеждането изглежда бързо. Проверката може да мине, докато всичко полезно зад тунела се проваля.

Прочетете двата вида доказателства поотделно, преди да промените таймер.

Какво всъщност пита проверката за живот

Обменът за живот се изпраща вътре в установената асоциация за сигурност на IKE и очаква отговор в зададен прозорец. Успехът означава, че реализацията на IKE у партньора все още е там и все още е готова да говори. Това не казва нищо за дъщерните асоциации за сигурност, които носят трафика, нищо за маршрутизацията отвъд шлюза и нищо за услугата, за която отворихте тунела. Това са три отделни въпроса с три отделни режима на отказ.

Това разграничение решава къде да гледате, когато сесията замлъкне. Партньор, който продължава да отговаря, докато пътят на данните е счупен, сочи към политика, маршрутизация или услуга надолу по веригата. Партньор, който спира да отговаря, сочи към достижимост или към собственото състояние на далечния край.

Прочетете асоциациите за сигурност преди браузъра

Контролното състояние и състоянието на данните се изброяват отделно, щом попитате демона, а броячите казват дали изобщо е бил направен опит. Дъщерна асоциация, която никога не е била инсталирана, изглежда съвсем различно от такава, която се е инсталирала и после е спряла да пропуска пакети, макар и двете да пораждат една и съща жалба от потребителя.

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

Запишете имената на състоянията дословно в заявката, заедно с броячите в момента на жалбата. Описание като тунелът е паднал скрива коя от двете асоциации е приключила и обикновено това е единственият факт, който си струва да имате.

Отказ на маршрут изглежда точно като мъртъв партньор

Шлюзът може да отговаря на контролни обмени, докато частен сървър е офлайн, препратен маршрут липсва или вътрешното разрешаване на имена се проваля напълно. От страна на клиента всяко от тези изглежда като сесия, която работи, и дестинация, която не работи. Проверявайте обратния път също толкова внимателно, колкото правия, защото асиметричната маршрутизация от далечната страна създава тишина само в една посока.

Тествайте предвиденото приложение директно и назовете адреса, който е опитало, вместо да тествате дали тунелът е вдигнат. Пинг към шлюза доказва, че шлюзът отговаря; той никога не е доказвал, че приложението е отговорило. Запишете точния адрес, който приложението е опитало. Този низ стеснява търсенето по-късно и това е единственият факт, който заявката обикновено пропуска.

Дръжте таймерите извън диагнозата

Скъсяването на интервала за откриване не е промяна на производителността и не добавя капацитет. При загуба на пакети то променя колко бързо се разпознава отказ, което може да направи симптома различен, без да подобри нищо. Запишете първо реалното време на отказа, после решете дали толерансът е грешен за връзката, която наистина имате.

Обновяванията на NAT преобразуването спадат към същата категория. Те поддържат преобразувания път използваем и не са доказателство, че отдалеченото приложение работи.

Пълна политика за възстановяване казва какво трябва да направи клиентът, когато партньор бъде обявен за мъртъв: рестартиране, затваряне или изчакване, и какво може да прави другият трафик, докато това става. Без нея същият инцидент се диагностицира отначало всяко тримесечие.