Portàtil itinerant: nom estable o adreça fixa d’oficina?

Obriu la consola de gestió des de casa, cerqueu el portàtil pel nom i obteniu una adreça que va deixar de ser vàlida quan va sortir de l’oficina. L’instint és portar l’adreça de l’oficina a l’adaptador VPN perquè tot continuï funcionant. Aquesta solució normalment trenca una altra cosa, perquè trobar un dispositiu, permetre’n el trànsit i mantenir viva una sessió són tres problemes diferents. Separeu-los abans de triar un disseny d’adreces.

Separeu els tres requisits

Anoteu quin dels tres falla realment. Una persona o eina no troba el servei; un servidor rebutja peticions perquè l’adreça d’origen no és en una llista; o una aplicació cau quan canvia la interfície. En un full de càlcul semblen iguals i necessiten solucions diferents.

La majoria de queixes d’itinerància van al primer calaix i es resolen al DNS. Anomenar una identitat estable és barat i cobreix el primer cas. Preservar l’adreça és car i només ajuda el segon si la política s’ha de reescriure igualment.

Feu que el nom sigui la cosa estable

Doneu al portàtil un nom que es resolgui a qualsevol adreça a la qual pugui arribar el sol·licitant. En aquest exemple l’adreça de l’oficina és 192.168.50.42, el grup d’accés remot assigna 10.90.0.42, i laptop17.corp.example segueix l’adjunció. Res no exigeix que coincideixi l’últim octet, i dissenyar al voltant d’aquesta coincidència crea feina sense cap benefici. El registre ha d’apuntar a l’adreça que el sol·licitant pot fer servir de debò, no a cada interfície que el portàtil hagi tingut mai.

dig +short laptop17.corp.example

Els resolvers fan memòria cau de les respostes, així que el canvi no és instantani per a tothom. Els TTL curts ajuden, i la lògica de reconnexió de l’aplicació ajuda més.

Quan la llista d’orígens permesos és la restricció real

Una llista d’orígens permesos veu l’adreça que rep el servei protegit, després de qualsevol traducció. Sovint és una adreça de passarel·la o NAT i no la del portàtil, i per això editar els registres DNS no arregla mai una petició rebutjada. Actualitzeu la política per a l’adreça que arriba realment, o substituïu la llista per una identitat autenticada.

Captureu una petició acceptada al servidor i llegiu el camp d’origen, després repetiu-ho des del camí remot. Si les dues adreces difereixen, la política necessita dues entrades o un altre mecanisme. Anoteu totes dues adreces amb l’entrada de política perquè la propera persona vegi per què n’hi ha dues. Reutilitzar una adreça que ja és activa al mateix enllaç és un problema de conflicte separat amb les seves pròpies regles de detecció.

Què exigeix realment la continuïtat

La continuïtat de la connexió és el requisit més difícil i el que més sovint es malinterpreta. Una connexió TCP s’identifica per les dues adreces i els dos ports, així que una adreça local nova és una altra connexió, digui el que digui el DNS. Les aplicacions que importen s’han de reconnectar, cosa que vol dir una capa de sessió o un client que reintenta, no un truc de xarxa. Observeu una sessió durant el moviment i la caiguda és immediata, no gradual.

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

Clonar una adreça MAC tampoc no ho resol. La identitat de l’arrendament DHCP pot fer servir un identificador de client explícit, i dues interfícies que comparteixen una identitat encara necessiten rutes coordinades. Tracteu la mobilitat com un disseny d’aplicació i d’assignació, i manteniu estable la identitat del dispositiu mentre la seva adreça segueix la xarxa.