Как работи IPsec на базата на маршрутите с интерфейс XFRM

IPsec на базата на маршрутите предава на таблицата за маршрутизиране решение, което преди са вземали селекторите на политики. В Linux частта, която прави това възможно, е интерфейсът XFRM: виртуално устройство, чийто трафик се съпоставя със състояние на IPsec чрез идентификатор на интерфейса, а не чрез селектор. Създаването му отнема една команда и не доказва нищо за съществуването на тунел. Устройството е кука между маршрутизирането и политиката за сигурност и двете страни на тази кука трябва да са конфигурирани, преди нещо да бъде защитено.

Какво е устройството и какво не е

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

Това е първото диагностично разделение. Маршрутът към устройството е факт за маршрутизирането, инсталираното състояние е факт за сигурността, а нарастващият брояч на устройството не е нито едно от двете. Когато хората казват, че тунелът е вдигнат, защото интерфейсът показва UP, те описват флаговете на връзката на виртуално устройство, което няма собствен партньор. Флагът означава, че устройството е създадено и включено, нищо повече.

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

Изградете едно в правилния ред

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

Вдигнете устройството, след което потвърдете идентификатора, който ядрото е записало, преди да пипате VPN конфигурацията:

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip link set xfrm0 up
ip -d link show xfrm0 | grep -o 'if_id [0-9]*'

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

Дръжте IKE и ESP извън маршрута на тунела

Маршрут по подразбиране, насочен към устройството XFRM, прихваща инкапсулираните пакети, както и трафика, който те носят. Резултатът е цикъл: шлюзът се опитва да изпрати своя ESP през тунела, който ESP трябва да изгради.

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

Каквото и да изберете, проверете, че външният пакет излиза неинкапсулиран. Бърза проверка е да направите ping до външния адрес на партньора, след като тунелът е вдигнат; ако това се провали, докато интерфейсът е вдигнат, подозирайте прихващане, а не достижимост. Същата логика важи за порта IKE, защото собственият UDP трафик на демона не бива да се насочва към устройството, което той се опитва да установи.

Проверете броячите на две места, преди да обвините криптирането

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

Прочетете и двете, после прочетете как демонът вижда дъщерната асоциация:

ip -s link show xfrm0
sudo ip xfrm state list | grep -E 'src|proto|mode'
sudo swanctl --list-sas

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

Решете кой инсталира маршрутите

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

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

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