iPhone Always On VPN: два тунелі можуть ділити одну віртуальну IP

На контрольованому iPhone з керованим профілем Always On телефон тримає тунель для кожного активного IP-інтерфейсу, тож стільникова мережа й Wi-Fi отримують кожен свій. Далі сервер перелічує дві IKE-асоціації безпеки для одного пристрою, часто зі спільним віртуальним адресом, і перший порив — назвати це циклом rekey і почати змінювати таймери. Цей порив зазвичай хибний. Пройдіть кроки нижче в тому порядку, у якому докази з'являються на сервері, і не чіпайте налаштування телефона, доки сервер не скаже, який у вас випадок.

Почніть із двох рядків, які сервер уже має

Перелічіть асоціації за допомогою swanctl --list-sas і прочитайте чотири поля в обох записах: віддалений адрес, автентифіковану ідентичність, призначену віртуальну IP і час створення. Два різні зовнішні адреси з однією ідентичністю та однією віртуальною IP — це форма, з якої почалося це питання, і її варто записати перед будь-якою зміною. Потім перевірте дочірні асоціації, прив'язані до кожної з них, бо селектори трафіку вирішують, чи зможе пошук за призначенням коли-небудь розрізнити два тунелі. Пара, що з'являється й зникає за секунди, — інша тварина, ніж пара, де обидві живуть годинами.

Перш ніж робити висновок, відсортуйте список за часом створення. Сусідство у виводі нічого не означає, а табличний список запрошує саме до цієї помилки.

Визначте, на яке перекриття ви дивитеся

Rekey IKEv2 і повторна автентифікація make-before-break навмисно створюють коротке перекриття, встановлюючи нову асоціацію до видалення старої. Часові позначки вирішують справу, бо стара SA, що зникає за секунду-дві після появи нової, — це оновлення, яке виконує свою роботу. Незалежні інтерфейсні тунелі ніколи так не виглядають: кожен існує, поки його інтерфейс піднятий, а видалення одного не випливає зі створення іншого.

Керована поведінка Always On від Apple діє за інтерфейсами, тому контрольований пристрій може законно виглядати зайнятішим за профіль, налаштований вручну. Перемикач автопідключення в застосунку провайдера не означає того ж, і звичайне правило on-demand теж. Огляд розгортання Apple описує модель за інтерфейсами; порівняйте свої два рядки з ним, перш ніж припускати цикл. Обидві форми також беруть з одного пулу на сервері, тож перекриття — ваш єдиний ранній сигнал.

Побачте, чому одна віртуальна адреса для двох тунелів ламає відповіді

Відповідь телефону адресується внутрішній адресі, і ядро вибирає вихідний тунель за призначенням і політикою, а не за інтерфейсом, який використав телефон. Дві одночасні асоціації з однією віртуальною IP і збіжними політиками залишають рішення про маршрутизацію без способу сказати, якій сесії належить відповідь. Деякі відповіді йдуть неправильним тунелем, і телефон показує з'єднання, що працює в один бік або вмирає, коли з'являється Wi-Fi. Два виводи команд доводять стан: swanctl --list-sas показує ту саму віртуальну IP на обох SA, а ip xfrm policy показує два однакові селектори.

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

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

Змініть пул або модель паралелізму, а не таймер rekey

У конфігурації swanctl унікальність — це явна політика на з'єднанні: unique = replace видаляє старіше з'єднання, коли встановлюється нове, а unique = keep відхиляє новачка. Обидва значення діють під час налаштування з'єднання, а не на дочірніх SA всередині нього.

connections {
  ios-alwayson {
    unique = replace
  }
}

Жодне зі значень не є нейтральним для клієнта за інтерфейсами. keep повертає охайний екран стану, відмовляючи другому тунелю, і ламає керовану конструкцію, тоді як replace зносить старіший тунель і є тим самим компромісом у протилежний бік. Якщо обидва тунелі справді потрібні, бекенд пулу має видавати різні оренди для однієї ідентичності, а його ключ оренди має розрізняти запити. Статична таблиця «ідентичність — адреса» охоче поверне ту саму адресу двічі й відтворить початкову проблему з більшою конфігурацією. Перевірте, як бекенд формує ключі оренди, перш ніж додавати друге статичне зіставлення.

Перевірте переходи, які справді впроваджуєте

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

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