Resumo

  • Na mesma VPN gateway e com o mesmo VPN-TIA, MOBIKE pode atualizar o endereço de acesso externo enquanto o binding no i-HA fica intencionalmente inalterado.
  • O recibo de continuidade precisa juntar mudança de acesso, IKE/MOBIKE, TIA, registro Mobile IPv4 quando necessário, reverse tunnel, encaminhamento e confirmação da aplicação.

O mesmo movimento produziu duas verdades

O nó entrou em outra rede externa e ganhou novo endereço. A gateway aceitou a atualização MOBIKE e manteve a associação IPsec. Para o plano exterior, houve uma mudança confirmada.

Dentro do túnel, o VPN-TIA continuou igual. Era esse CoA que o i-HA associava ao home address. Para o agente interno, nada mudou. Seu silêncio é esperado, não uma confirmação de que o acesso físico permaneceu.

O erro nasce quando o primeiro resultado verde passa a significar “sessão corporativa restaurada”.

Três endereços, três superfícies

O home address Mobile IPv4 permanece constante. A gateway atribui o TIA, normalmente roteável internamente, e o cliente o registra como care-of address. A rede externa fornece ainda o endereço que envolve o IPsec.

MOBIKE move o endereço exterior. O TIA pode continuar, e o home address continua acima dos dois. Um campo único de “IP atual” apaga qual coordenada mudou e quem tem autoridade para confirmá-la.

Estabilidade reduz sinalização e visibilidade

Manter o TIA evita atualizar o i-HA em toda troca de rede externa. O Mobile IP tunnel dentro do IPsec fica estável. Ao mesmo tempo, o histórico do agente não consegue mostrar os anexos externos sucessivos.

É preciso correlacionar a SA, a gateway e a alocação TIA com os eventos MOBIKE. Se uma reconexão ou outra gateway trouxer novo TIA, o nó deve registrar o novo CoA. A ausência desse segundo commit deixa o túnel exterior saudável e o binding interior antigo.

Dois túneis não formam um único recibo

No modo mc, Mobile IPv4 roda dentro de IPsec e usa reverse tunneling pelo home agent. A resposta MOBIKE prova aceitação da rota externa; a Registration Reply prova aceitação do binding. Nenhuma prova que pacotes atravessaram as duas camadas.

Seletores, NAT, encaminhamento reverso, perda e aplicação ficam depois dos controles. Contadores nas duas bordas e confirmação do destino são necessários para afirmar continuidade de serviço.

A fronteira dispara operações paralelas

Depois de mudança de conectividade, o nó pode enviar MOBIKE à gateway e um registro direto ao i-HA ao mesmo tempo. Gateway respondendo sem i-HA apoia a classificação externa; uma resposta interna protegida conforme TNC apoia a interna. Não se envia tráfego normal durante a decisão.

Ao sair da empresa, estabelecer a VPN só cria o canal. Sem resposta direta do i-HA, o cliente ainda registra o TIA através do túnel e espera o retorno antes de usar o home address.

Tráfego direto não herda continuidade

Clientes podem permitir Internet direto fora da VPN. RFC 5266 não impede isso, mas esse tráfego não recebe mobilidade nem continuidade da solução. O tráfego do Mobile IP tunnel sempre passa pela gateway.

Bytes na interface nova não bastam como prova de serviço corporativo. É preciso separar fluxo direto, IPsec e Mobile-IP-em-IPsec. NAT traversal também pode existir nas duas camadas, com estados independentes.

Recibo de mobilidade em camadas

Registre interface e endereços externos, SA IKE, gateway e troca MOBIKE, TIA e seu lifetime, home address e CoA, registro e versão do binding, caminho direto ou pelo VPN ao i-HA, TNC, autenticação e replay, reverse tunnel, seletores, NAT, contadores de ambas as bordas, recuperação do transporte e confirmação da aplicação.

O modelo deve aceitar MOBIKE alterado com binding igual. Deve rejeitar TIA novo sem atualização interna e qualquer transformação de resposta local em conclusão de ponta a ponta.

Fontes