Portátil en itinerancia: nome estable ou enderezo fixo de oficina?

Abre a consola de administración desde casa, busca o portátil polo nome e obtén un enderezo que deixou de ser válido cando saíu da oficina. O instinto é trasladar o enderezo da oficina ao adaptador VPN para que todo siga funcionando. Esa solución adoita romper outra cousa, porque atopar un dispositivo, permitir o seu tráfico e manter viva unha sesión son tres problemas distintos. Sepáreos antes de elixir un deseño de enderezos.

Separe os tres requisitos

Anote cal dos tres falla realmente. Unha persoa ou ferramenta non atopa o servizo; un servidor rexeita peticións porque o enderezo de orixe non está nunha lista; ou unha aplicación cae cando cambia a interface. Nunha folla de cálculo parecen iguais e precisan correccións distintas.

A maioría das queixas de itinerancia caen no primeiro caixón e corríxense no DNS. Nomear unha identidade estable é barato e cobre o primeiro caso. Preservar o enderezo é caro e só axuda ao segundo se a política se reescribe de todos os xeitos.

Faga que o nome sexa o estable

Déalle ao portátil un nome que resolva a calquera enderezo alcanzable por quen chama. Neste exemplo o enderezo da oficina é 192.168.50.42, o conxunto de acceso remoto entrega 10.90.0.42, e laptop17.corp.example segue a conexión. Nada esixe que coincida o último octeto, e deseñar arredor desa coincidencia crea traballo sen beneficio. O rexistro debe apuntar ao enderezo que quen chama pode usar de verdade, non a cada interface que o portátil tivese xamais.

dig +short laptop17.corp.example

Os resolutores cachéan respostas, así que o cambio non é instantáneo para todos. Os TTL curtos axudan, e a lóxica de reconexión da aplicación axuda máis.

Cando a lista de orixes permitidas é a restrición real

Unha lista de orixes permitidas ve o enderezo que recibe o servizo protexido, despois de calquera tradución. A miúdo é un enderezo de pasarela ou NAT e non o do propio portátil, por iso editar os rexistros DNS nunca repara unha petición rexeitada. Actualice a política para o enderezo que chega realmente, ou substitúa a lista por unha identidade autenticada.

Capture unha petición aceptada no servidor e lea o campo de orixe, e despois repítao desde o camiño remoto. Se os dous enderezos difiren, a política precisa dúas entradas ou outro mecanismo. Anote ambos os enderezos xunto coa entrada de política para que a seguinte persoa vexa por que hai dous. Reutilizar un enderezo que xa está activo na mesma ligazón é un problema de conflito aparte, coas súas propias regras de detección.

Que esixe realmente a continuidade

A continuidade da conexión é o requisito máis difícil e o que máis se malinterpreta. Unha conexión TCP identifícase por ambos os enderezos e ambos os portos, así que un enderezo local novo é outra conexión, diga o que diga o DNS. As aplicacións que importan deben reconectarse, o que significa unha capa de sesión ou un cliente que reintenta, non un truco de rede. Observe unha sesión durante o movemento e a caída é inmediata, non gradual.

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

Clonar un enderezo MAC tampouco resolve isto. A identidade do arrendamento DHCP pode usar un identificador de cliente explícito, e dúas interfaces que comparten unha identidade seguen precisando rutas coordinadas. Trate a mobilidade como un deseño de aplicación e asignación, e manteña estable a identidade do dispositivo mentres o seu enderezo segue a rede.