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 с активной сессией, затем вернитесь и проверьте, что ответы приходят в обе стороны. Сделайте это дважды, потому что именно на втором переходе обычно появляется устаревшая политика. Проверьте на сервисе, который отвечает на открытом вами соединении, и повторите выход, пока туннель несёт трафик, а не простаивает. Телефон, который умеет отправлять, но не получать, выглядит здоровым в журнале рукопожатия и сломанным в браузере.

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