iOS IKEv2 і strongSwan: узгодження не вибрано — виправте список

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

Де шлюз оголошує свою політику

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

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

Тому профіль, скопійований з іншого VPN-застосунку, може працювати там, де ваш ні: той застосунок надсилав інший список.

Назви мають збігатися, а не покращуватися

Два переклади плутають тих, хто переносить значення зі strongSwan в iOS. Алгоритм цілісності, записаний як SHA1 у пропозиції IKE, іде в усіченій формі, яку iOS називає .SHA96. Група Діффі — Геллмана, записана як modp1024, — це група 2, яку iOS називає .group2. Заміна на SHA-256 або групу 14 не дасть узгодження зі шлюзом, який приймає лише стару пару. Клієнт має описати той самий алгоритм, а не сильніший.

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

Дочірня пропозиція падає пізніше й тихіше

Налаштуйте й дочірню асоціацію безпеки, а не лише IKE. Коли збігаються лише параметри IKE, тунель автентифікується і потім не передає трафік, а це значно тихіша відмова, ніж відхилення. Задайте шифрування, цілісність, групу й час життя дочірньої в одному проході. Тримайте час життя клієнта на рівні шлюзу або нижче, бо наполягання на довшому дає те саме повідомлення no proposal chosen з іншої причини. Неузгодженість там виглядає точно так само, як неузгодженість IKE в журналі.

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

Залишайте старий набір лише поки він потрібен

Закріплення SHA-1 з групою 1024 біти — це міст, а не мета. Обидва застаріли, і новіші клієнти можуть їх взагалі відхилити, а отже, профіль відмовить на наступному пристрої без будь-яких змін з вашого боку. Вважайте закріплення тимчасовим і запишіть це в протоколі.

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