IKE казва, че тунелът е вдигнат, дъщерният SA липсва и двете твърдения могат да са верни едновременно. Установената управляваща връзка не е връзка за данни и двата обекта имат отделни животи, преговори и режими на отказ. Да съобщиш първото като свързаност е начинът, по който заявката стига до твърдението, че тунелът е вдигнат, докато нищо не работи. Четете списъка с връзки, а не обобщаващия етикет на свързаността, защото този списък е единственото място, където липсващият обект се вижда. Следва редът, в който списъкът придобива смисъл.

Две връзки, две задачи

IKE SA носи управляващия канал: идентичности, ключове и предложенията за самата управляваща размяна. Дъщерният SA носи защитата ESP, със свои алгоритми и свои селектори на трафик. Удостоверяването и създаването на дъщерен SA обикновено вървят заедно, защото първият дъщерен SA се договаря вътре в IKE_AUTH и точно това обединяване изненадва хората с разделянето.

Това обяснява и двете форми на отказ, които ще срещнете. Дъщерен SA, отхвърлен по време на началната размяна, обикновено смъква със себе си и IKE SA, така че изобщо не виждате установен управляващ канал. IKE SA, стоящ сам, по-често означава, че първият дъщерен SA е успял, а по-късен опит за създаване на дъщерен SA се е провалил, например при смяна на ключове. Времевите маркери разделят тези случаи по-бързо от всеки преглед на конфигурацията.

Кой слой отказа

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

Понякога липсата на дъщерен SA е дизайнът. IKE SA без дъщерен SA е дефинирано разширение, използвано там, където връзката за данни трябва да се създава при поискване, така че липсата е правилна и дъщерният SA се появява, когато пристигне подходящ трафик. Бележките на strongSwan за IKEv2 покриват както стила при поискване, така и настройките на предложението, които решават първия случай.

Проверете за конфигурация при поискване или капан, преди да диагностицирате повреда. Ако дъщерните SA се създават лениво, липсата на дъщерен SA в покой е очакваното състояние и истинската проверка е дали трафикът вдига такъв. Тази проверка отделя и ленивия дизайн от тихия отказ, защото неуспешното създаване оставя задействащото условие без отговор, а не просто в покой.

После питайте за пътя на данните

Щом има дъщерен SA, броячите отговарят на следващия въпрос. ip -s xfrm state показва броя пакети и байтове за всяка връзка, а дъщерен SA, който не носи нищо, докато генерирате трафик, сочи към съпоставяне или маршрутизация към липсваща връзка. swanctl --list-sas отпечатва селекторите на дъщерния SA до тези броячи и точно това потвърждава, че пакетът се намира в приетия набор.

Дръжте успешното удостоверяване и неуспешната размяна на дъщерния SA отделно в описанието. Доклад, който твърди, че удостоверяването се е провалило, изпраща следващия инженер при хранилището на сертификати, а точната фраза е много по-кратка: IKE SA се вдигна, а дъщерният SA за този поток така и не беше приет.

Съпоставете двата края

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

Поправете договарянето на дъщерния SA, после тествайте отново с трафик в желания селектор. Това е единственият тест, който доказва, че липсващият обект вече присъства, защото списък с връзки, обновен в покой, може да изглежда еднакъв преди и след поправката.

Подобни статии