Portátil em roaming: nome estável ou endereço fixo do escritório?

Abre a consola de gestão de casa, procura o portátil pelo nome e recebe um endereço que deixou de ser válido quando saiu do escritório. O instinto é levar o endereço do escritório para o adaptador VPN para que tudo continue a funcionar. Essa correção costuma quebrar outra coisa, porque encontrar um dispositivo, permitir o seu tráfego e manter uma sessão viva são três problemas diferentes. Separe-os antes de escolher um desenho de endereços.

Separe os três requisitos

Anote qual dos três está realmente a falhar. Uma pessoa ou ferramenta não encontra o serviço; um servidor recusa pedidos porque o endereço de origem não está numa lista; ou uma aplicação cai quando a interface muda. Numa folha de cálculo parecem iguais e exigem correções diferentes.

A maioria das queixas de roaming cai no primeiro cesto e resolve-se no DNS. Dar nome a uma identidade estável é barato e cobre o primeiro caso. Preservar o endereço é caro e só ajuda o segundo se a política for reescrita de qualquer forma.

Faça do nome a coisa estável

Dê ao portátil um nome que resolva para qualquer endereço alcançável por quem chama. Neste exemplo o endereço do escritório é 192.168.50.42, o conjunto de acesso remoto entrega 10.90.0.42, e laptop17.corp.example segue a ligação. Nada exige que o último octeto coincida, e desenhar em torno dessa coincidência cria trabalho sem benefício. O registo deve apontar para o endereço que quem chama pode realmente usar, não para cada interface que o portátil alguma vez teve.

dig +short laptop17.corp.example

Os resolvedores guardam respostas em cache, por isso a mudança não é imediata para todos. TTL curtos ajudam, e a lógica de reconexão da aplicação ajuda mais.

Quando a lista de origens permitidas é a restrição real

Uma lista de origens permitidas vê o endereço que o serviço protegido recebe, depois de qualquer tradução. É muitas vezes um endereço de gateway ou NAT e não o do próprio portátil, e é por isso que editar registos DNS nunca repara um pedido recusado. Atualize a política para o endereço que chega realmente, ou substitua a lista por uma identidade autenticada.

Capture um pedido aceite no servidor e leia o campo de origem, e depois repita a partir do caminho remoto. Se os dois endereços forem diferentes, a política precisa de duas entradas ou de outro mecanismo. Registe ambos os endereços com a entrada de política para que a próxima pessoa veja porque há dois. Reutilizar um endereço que já está ativo na mesma ligação é um problema de conflito separado, com as suas próprias regras de deteção.

O que a continuidade realmente exige

A continuidade da ligação é o requisito mais difícil e o que mais vezes é mal interpretado. Uma ligação TCP é identificada por ambos os endereços e ambas as portas, por isso um novo endereço local é outra ligação, diga o que disser o DNS. As aplicações que importam têm de se reconectar, o que significa uma camada de sessão ou um cliente que tenta novamente, não um truque de rede. Observe uma sessão durante a mudança e a queda é imediata, não gradual.

ss -tnp state established '( dport = :443 )'

Clonar um endereço MAC também não resolve isto. A identidade da concessão DHCP pode usar um identificador de cliente explícito, e duas interfaces que partilham uma identidade continuam a precisar de rotas coordenadas. Trate a mobilidade como um desenho de aplicação e de atribuição, e mantenha estável a identidade do dispositivo enquanto o seu endereço segue a rede.