Коли IKEv2 повертає TS_UNACCEPTABLE, порівняйте реальні підмережі

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

Спершу запишіть задумані пари

Перш ніж торкатися конфігурації, перелічіть чотири значення: діапазон джерела ініціатора, його діапазон призначення та ту саму пару з погляду відповідача. Запишіть також родину адрес кожного з них. Діапазон IPv4 і діапазон IPv6 — різні типи селекторів, і жоден не можна згорнути в корисне навантаження іншого.

Додайте будь-яке обмеження протоколу або порту, яке несе політика. Правило, що дозволяє лише TCP 445 до файлового сервера, описує вужчу множину, ніж підмережа, у якій воно міститься. Якщо залишити це поза нотатками, результат переговорів виглядатиме неузгодженим із причин, яких ви не бачите.

Поміняйте позначки перед порівнянням

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

Відповідач може звузити пропозицію до прийнятної підмножини замість того, щоб її відхилити. Такий результат гірший за чисту невдачу, бо працює наполовину. Попросіть 10.0.0.0/16, коли політика дозволяє 10.0.5.0/24, і можете залишитися з дочірньою SA, що покриває лише ту /24. Відповідає один хост, усе інше залишається ззовні, і ніщо в клієнті про це не каже. Читайте прийняті селектори, а не запитані, перш ніж дійти висновку, що переговори вдалися.

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

Прочитайте відмову з однієї спроби

Зберіть обидва журнали з однієї спроби підключення. Збережений профіль показує, що ви налаштували, а не що було запропоновано, а в strongSwan swanctl --log друкує отримане сповіщення разом із селекторами, які воно несло.

Далі перевірте, що насправді встановлено. swanctl --list-sas показує селектори дочірньої SA, а ip xfrm policy показує ті самі діапазони як записи політики ядра. Дочірня SA у цьому списку із селекторами, яких ви не задумували, — це подія звуження; відсутність дочірньої SA плюс TS_UNACCEPTABLE у журналі — це відмова.

Поки ви там, відокремте близьких сусідів. INVALID_SELECTORS скаржиться на селектор усередині встановленої дочірньої SA, тоді як INTERNAL_ADDRESS_FAILURE означає, що відповідач не зміг виділити віртуальну адресу, а це проблема пулу, а не покриття.

Перевірте, що тихо зменшує множину

Три речі зменшують множину селекторів, нічого не кажучи. Політика відповідача — перша: списки підмереж, групові правила або авторизація за користувачем зводять пропозицію до підмножини. Родина адрес — друга: клієнт із двома стеками часто пропонує IPv6 поряд з IPv4 і отримує відмову для діапазонів, які шлюз ніколи не налаштовував.

Обмеження протоколу й порту — третя. Там, де політика дозволяє лише TCP 445, дочірня SA може піднятися, тоді як ICMP і UDP залишаються поза нею, і користувач повідомляє про зламаний тунель, хоча дозволено було лише один протокол.

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

Доведіть покриття відповідним трафіком

Після встановлення дочірньої SA надішліть один запит, який точно потрапляє всередину прийнятих діапазонів. Дивіться на лічильники, а не на значок стану: ip -s xfrm state і лічильники за ip xfrm policy зростають, коли пакет зіставляється й захищається. Кількість байтів, що після реального трафіку лишається нульовою, означає, що ядро так і не вибрало цю політику.

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

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