Кратко

  • При том же VPN-шлюзе и VPN-TIA MOBIKE меняет внешний адрес доступа, а binding внутреннего i-HA закономерно остаётся прежним.
  • Доказательство непрерывности связывает доступ, IKE/MOBIKE, TIA, нужную регистрацию Mobile IPv4, reverse tunnel, передачу пакетов и подтверждение приложения.

Движение существовало только в одной системе координат

Узел сменил внешнюю сеть. MOBIKE сообщил новый адрес шлюзу, и IPsec SA продолжила работу по новому пути. Внешний peer увидел и принял перемещение.

Внутри туннеля TIA не изменился. i-HA по-прежнему связывал home address с тем же CoA. Его молчание означает отсутствие изменения внутренней координаты, а не отсутствие физического перехода.

Ошибка возникает, когда панель превращает «MOBIKE принят» в «корпоративная сессия восстановлена».

Одного поля IP недостаточно

Home address стабилен в обоих режимах. VPN-шлюз выдаёт внутренне маршрутизируемый TIA, который регистрируется как CoA. Снаружи находится адрес сети доступа, обновляемый MOBIKE.

У каждой координаты свой владелец и срок. Без типа адреса даже подлинная запись теряет смысл: непонятно, какой слой изменился и какой остался намеренно стабильным.

Оптимизация создаёт границу наблюдения

Стабильный TIA избавляет i-HA от регистрации каждого внешнего перехода и сохраняет Mobile IP tunnel внутри IPsec. Поэтому журнал агента не способен восстановить последовательность внешних сетей.

Нужно связывать MOBIKE-события с SA, шлюзом, выдачей TIA и Mobile IPv4 binding. Новый TIA после переподключения или смены шлюза требует Registration Request к i-HA. Внешний и внутренний commits происходят отдельно.

Вложенные туннели не дают общей квитанции

Режим mc помещает Mobile IPv4 в IPsec и требует reverse tunneling через home agent. Ответ MOBIKE подтверждает внешний адрес, Registration Reply — внутренний binding.

Ни один не подтверждает прохождение обоих туннелей, состояние NAT, selectors, потери или результат приложения. Нужны счётчики на обеих границах и наблюдение получателя.

Переход границы запускает параллельные обмены

После изменения связи узел одновременно отправляет MOBIKE шлюзу и прямой незашифрованный запрос i-HA. Ответ только шлюза поддерживает «снаружи»; защищённый ответ i-HA по условиям TNC — «внутри». Во время определения обычный трафик не должен идти.

При выходе из предприятия успешный VPN лишь создаёт канал. Если прямого ответа i-HA нет, через туннель выполняется Mobile IPv4 registration, и только затем home address готов к связи.

Прямые пакеты не наследуют обещание

VPN-клиент может выпускать Internet-трафик напрямую. RFC 5266 не запрещает это, но такой поток не получает мобильность и session continuity решения. Трафик Mobile IP tunnel всегда идёт через шлюз.

Пакеты на новом интерфейсе не доказывают восстановление корпоративного сервиса. Следует различать direct, IPsec и Mobile-IP-in-IPsec. NAT traversal также может иметь независимое состояние на двух уровнях.

Многоуровневая квитанция

Храните интерфейс и старый/новый внешний адрес, IKE SA, шлюз и MOBIKE commit, TIA и его lifetime, home address и CoA, регистрацию и версию binding, прямой либо VPN-путь к i-HA, TNC, аутентификацию и replay, reverse tunnel, selectors, NAT, счётчики обеих границ, восстановление транспорта и ответ приложения.

Нормальна смена внешнего пути при прежнем binding. Опасны новый TIA без обновления i-HA и любое превращение раннего успеха в сквозной результат.

Источники