Portatile in roaming: nome stabile o indirizzo fisso dell’ufficio?

Aprite la console di gestione da casa, cercate il portatile per nome e ottenete un indirizzo che ha smesso di essere valido quando ha lasciato l’ufficio. L’istinto è portare l’indirizzo dell’ufficio sull’adattatore VPN perché tutto continui a funzionare. Quel rimedio di solito rompe qualcos’altro, perché trovare un dispositivo, consentirne il traffico e mantenere viva una sessione sono tre problemi diversi. Separateli prima di scegliere un progetto di indirizzi.

Separate i tre requisiti

Scrivete quale dei tre sta davvero fallendo. Una persona o uno strumento non trova il servizio; un server rifiuta le richieste perché l’indirizzo di origine non è in un elenco; oppure un’applicazione cade quando cambia l’interfaccia. Su un foglio di calcolo sembrano uguali e richiedono correzioni diverse.

La maggior parte dei reclami di roaming finisce nel primo cesto e si risolve nel DNS. Dare un nome a un’identità stabile costa poco e copre il primo caso. Preservare l’indirizzo costa molto e aiuta il secondo solo se la politica viene riscritta comunque.

Fate del nome la cosa stabile

Date al portatile un nome che si risolva verso qualsiasi indirizzo raggiungibile dal chiamante. In questo esempio l’indirizzo dell’ufficio è 192.168.50.42, il pool di accesso remoto assegna 10.90.0.42, e laptop17.corp.example segue il collegamento. Nulla richiede che l’ultimo ottetto coincida, e progettare intorno a quella coincidenza crea lavoro senza beneficio. Il record deve puntare all’indirizzo che il chiamante può davvero usare, non a ogni interfaccia che il portatile abbia mai avuto.

dig +short laptop17.corp.example

I resolver mettono in cache le risposte, quindi il cambiamento non è immediato per tutti. TTL brevi aiutano, e la logica di riconnessione dell’applicazione aiuta di più.

Quando l’elenco delle origini consentite è il vero vincolo

Un elenco di origini consentite vede l’indirizzo che riceve il servizio protetto, dopo qualsiasi traduzione. Spesso è un indirizzo di gateway o NAT e non quello del portatile, ed è per questo che modificare i record DNS non ripara mai una richiesta rifiutata. Aggiornate la politica per l’indirizzo che arriva davvero, oppure sostituite l’elenco con un’identità autenticata.

Catturate una richiesta accettata sul server e leggete il campo di origine, poi ripetete dal percorso remoto. Se i due indirizzi differiscono, la politica ha bisogno di due voci o di un altro meccanismo. Annotate entrambi gli indirizzi con la voce di politica perché la persona successiva veda perché ce ne sono due. Riusare un indirizzo già attivo sullo stesso collegamento è un problema di conflitto separato, con le sue regole di rilevamento.

Che cosa richiede davvero la continuità

La continuità della connessione è il requisito più difficile e quello più spesso frainteso. Una connessione TCP è identificata da entrambi gli indirizzi e da entrambe le porte, quindi un nuovo indirizzo locale è un’altra connessione, qualunque cosa dica il DNS. Le applicazioni che contano devono riconnettersi, il che significa uno strato di sessione o un client che riprova, non un trucco di rete. Osservate una sessione durante lo spostamento e la caduta è immediata, non graduale.

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

Clonare un indirizzo MAC non risolve nemmeno questo. L’identità del lease DHCP può usare un identificatore client esplicito, e due interfacce che condividono un’identità hanno comunque bisogno di rotte coordinate. Trattate la mobilità come un progetto di applicazione e di allocazione, e mantenete stabile l’identità del dispositivo mentre il suo indirizzo segue la rete.