Дочірня SA IPsec піднята, але лічильники пакетів залишаються нульовими

Ви підняли тунель, таймер переузгодження ключів відраховує час, а обидва напрямки досі показують нуль пакетів. Ніщо в цій парі чисел не каже, що партнер відхилив ваш тунель: встановлена CHILD SA з порожніми лічильниками — це нормальний стан асоціації, з якою ще нічого не збіглося. Завдання — довести, що пакет мав збігтися, а потім знайти точку, де він пішов зі шляху, описаного селекторами. Зробіть це один раз, по порядку, і тримайте запит однаковим між запусками.

Що насправді доводить нульовий лічильник

CHILD SA — це пара селекторів плюс ключі та SPI, які шифрують трафік, що потрапляє в ці діапазони. Встановити її означає лише те, що обидва партнери погодилися щодо цих діапазонів і виведених ключів; ядро триматиме її годинами, навіть якщо не прийде жоден пакет. Тож питання ніколи не в тому, чи існує тунель, а в тому, чи потрапив хоч один пакет, надісланий вашим тестом, у діапазони, узгоджені двома партнерами. Якщо жоден не потрапив, лічильники залишаються нульовими, і асоціація завершується невикористаною в кінці свого часу життя.

Ця різниця змінює те, що ви перевіряєте першим. Відхилена пропозиція, збій автентифікації або вмираюча IKE SA з'являються в журналі чи в списку SA, а не як тихий нуль. Тунель, який чисто узгоджується, а потім простоює, вказує радше на зіставлення, маршрутизацію або джерело тестового трафіку.

Надішліть потік, який можете описати до надсилання

Виберіть пункт призначення всередині захищеної підмережі й відкрийте до нього нове з'єднання; сторінка, завантажена годину тому, може прийти з кешу, а кешована відповідь ніколи не торкається тунелю. Потім запишіть чотири значення, поки запит ще гіпотетичний: адресу джерела, яку зв'яже застосунок, пункт призначення, родину адрес і назву або пару селекторів дочірньої SA, яку ви спостерігаєте. Саме цей запис перетворює плаский лічильник на перевірюване твердження.

Адреса джерела — це значення, яке люди пропускають, і саме воно найчастіше ламає тест. Ноутбук із дротовою адресою, адресою Wi-Fi та адресою тунелю може зв'язати будь-яку з них залежно від пошуку маршруту, і лише одна може лежати в узгодженому діапазоні. Використайте інструмент, що дозволяє закріпити джерело, наприклад ping -I 10.1.0.5 10.2.0.9 або curl --interface 10.1.0.5, щоб пакет не міг тихо вибрати іншу адресу. Коли закріплений запуск зсуває лічильники, а незакріплений ні, ви знайшли проблему маршрутизації, а не проблему IPsec.

Які числа читати і де вони живуть

У Linux ip -s xfrm state виводить кожну асоціацію з рядком lifetime current:, сума байтів і сума пакетів у якому належать лише цій SA, а далі йде рядок stats: із лічильниками повторів і помилок. На партнері strongSwan swanctl --list-sas виводить один рядок in і один рядок out для кожної встановленої дочірньої SA, кожен закінчується числом байтів і числом пакетів; старі інструменти stroke називають ту саму пару bytes_i і bytes_o. Читайте два напрямки окремо, бо саме той, що залишився пласким, є знахідкою. Додавання їх разом приховує саме ту асиметрію, яку ви шукаєте.

Обидва подання стосуються асоціації, тож переузгодження встановлює нову пару SPI, і ваша базова лінія повертається до нуля без жодної поломки. Запишіть SPI, який спостерігаєте, до спрацювання таймера переузгодження, інакше порівняєте нову SA зі старим числом. Якщо вихідний напрямок зростає, а вхідний залишається пласким, селектор збігся, але відповідь так і не повернулася, що переводить розслідування на пересилання в партнера та його власну політику. Документація з налаштування IKEv2 strongSwan описує життєвий цикл дочірньої SA та час переузгодження, що стоїть за цими числами.

Точка спостереження — це окрема змінна від джерела пакета. Апаратне розвантаження може збільшувати лічильники асоціації, тоді як програмний захват на інтерфейсі нічого не показує, бо розвантажені пакети оминають гак, на якому сидить захват, і вхідний трафік може відхилятися так само. Коли ці двоє не згодні, використайте лічильники, щоб відповісти, чи щось збіглося, а захват — щоб відповісти, як виглядав пакет.

Маршрут, селектори та де народився пакет

Порівняйте три речі поруч: маршрут, який ядро вибирає для вашого пункту призначення, політику, що спрямовує трафік у тунель, і пару селекторів, узгоджену дочірньою SA. ip route get 10.2.0.9 from 10.1.0.5 називає інтерфейс і джерело, які використало б ядро, а це часто не та пара, яку ви припускали. ip xfrm policy показує шаблони й селектори, встановлені локально, тоді як swanctl --list-sas показує, на чому погодився партнер. Пошук, що відправляє пакет через фізичний інтерфейс, взагалі не доходить до політики, тож лічильники не можуть зрушити.

Незбіги бувають кількох видів, які з боку лічильника виглядають однаково. Пункт призначення IPv6 поза селектором IPv4, адреса джерела з неправильної підмережі та політика вужча за дочірню SA дають той самий нуль. Спершу виправте найвужчу причину, бо розширення селектора лише заради зсуву числа змінює те, що захищає тунель.

Далі йде джерело пакета — пастка, яку шлюз ставить для власного оператора. Трафік, який шлюз породжує сам, зіставляється з вихідною політикою, тоді як пакет, який він пересилає за клієнта, зіставляється з політикою пересилання, тож ping із коробки може вдатися на шляху, яким не піде жоден клієнт.

Одна зворотна зміна й звіт, що витримує перевірку

Змініть один елемент, повторіть той самий запит і прочитайте ті самі лічильники. Очищення всіх правил брандмауера або заміна всіх селекторів одразу зсуне число й знищить докази, які казали вам чому. Якщо другий запуск досі показує нуль, ви усунули одну гіпотезу замість того, щоб згаяти день.

Запишіть знахідку у формі, яку інший може відтворити: назва дочірньої SA, прийняті діапазони, закріплене вами джерело, перевірений пункт призначення, напрямок, що залишився нульовим, і SPI, який ви читали. Це речення відокремлює асоціацію, якою ніхто не користувався, від віддаленого застосунку, що отримав трафік і відмовив. Відкотіть зміну, коли вона не зрушила лічильники, і збережіть запис; наступна людина почне там, де ви зупинилися. Нічого в тунелі не довелося перебудовувати, і в цьому сенс перевірки зіставлення перед тим, як торкатися конфігурації.