Защо IPsec политиката за сигурност не е ред от таблицата за маршрутизация

Пуснете ping към 10.20.0.5 през тунела и нищо не се връща, докато таблицата за маршрутизация настоява, че тази подмрежа е достъпна. Маршрутизацията и IPsec отговарят на различни въпроси и само един от тях е за достъпността. Търсенето напред избира път, после базата с политики за сигурност решава дали този път трябва да бъде защитен, оставен както е или отказан. Когато двете се разминат, пакетът умира тихо, затова ги четете в този ред.

Започнете с търсенето, не с таблицата

Попитайте ядрото какво наистина ще направи: ip route get 10.20.0.5 показва избрания маршрут, изходящия интерфейс и адреса на източника, който ще използва. Префикс, правило за политика, маркировка или предпочитан източник могат да променят този отговор, затова живото търсене е по-добро от четене на таблицата на око.

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

Съпоставете селекторите от двете страни

Базата с политики има свои записи и всеки от тях посочва посока, източник, дестинация и протокол, а после казва какво да се случи с отговарящите пакети. Използвайте ip xfrm policy, за да ги изброите; флаговете показват дали действието е защита, заобикаляне или блокиране. Политика, чиито селектори са по-широки или по-тесни от тестовия поток, няма да съвпадне с него и пакетът излиза незащитен. Това е повредата, която търсите, а не липсващ маршрут.

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

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

Съвпадащата политика само казва, че пакетът трябва да бъде защитен; ядрото все още се нуждае от асоциация за сигурност, за да извърши защитата. Изброете ги с ip xfrm state или с swanctl --list-sas, когато strongSwan води преговорите, и прочетете селекторите и броячите на всеки запис.

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

Какво все още изисква тунелът на базата на маршрут

Интерфейсът XFRM прави тунела да изглежда като устройство, към което може да се маршрутизира, което е наистина полезно. Той не премахва политиката и състоянието, които решават какво става, щом пакетът стигне там. Маршрутът дава следващ хоп и нищо повече.

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

Изяснете собствеността, преди да редактирате нещо

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

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