Quale identificatore serve alla tua prenotazione VPN?

Tre condizioni decidono quale identificatore debba usare una prenotazione: quale sistema distribuisce l’indirizzo, se quel sistema vede mai un frame di livello 2 e cosa usa come chiave del client. Un router domestico con DHCP, una VPN in bridge e un tunnel instradato rispondono diversamente a queste domande. Scegliere l’identificatore è più duraturo che cercare di congelare ogni indirizzo MAC che un adattatore riporta, perché l’identificatore è ciò che l’allocatore legge davvero.

Parti dall’allocatore e procedi a ritroso; l’identificatore lato client è ciò che quel sistema accetta.

Chiedi prima all’allocatore

Un server DHCP assegna da un pool e confronta le prenotazioni con un identificatore che riconosce, che può essere l’indirizzo hardware, una stringa di identificatore client o un DUID a seconda della versione del protocollo. Un server VPN assegna dal proprio pool e confronta con ciò che espone il suo modello di configurazione, spesso il Common Name autenticato. Una rete in bridge può affidare lo stesso problema al server DHCP che già serve la LAN. Ognuno è una ricerca diversa, e una prenotazione valida in uno è invisibile agli altri.

Conferma cosa vede realmente il server prima di configurare qualsiasi cosa. Una prenotazione che nomina l’identificatore sbagliato fallisce in silenzio: il client riceve semplicemente un indirizzo dal pool, e l’errore sembra un problema del client.

Dove un indirizzo MAC conta ancora

Su un collegamento Ethernet o Wi-Fi fisico, l’indirizzo hardware identifica un’interfaccia su quel segmento. Le funzioni di privacy lo ruotano, gli adattatori virtuali ne creano di nuovi, e un portatile può presentare valori diversi in Wi-Fi e su una docking station. Un tunnel TUN instradato trasporta pacchetti IP e non trasmette l’identità wireless originale a un server DHCP remoto, quindi una prenotazione basata su MAC su quel percorso non ha nulla da confrontare. TAP è diverso: trasporta frame Ethernet e può unirsi a un dominio in bridge dove gli identificatori di livello 2 contano ancora.

Anche lì, l’indirizzo rilevante è quello usato su quel dominio, non automaticamente quello dell’uplink fisico.

Gli indirizzi dei tunnel e le chiavi dei peer hanno il proprio spazio

Un deployment OpenVPN instradato assegna indirizzi tramite il proprio modello: configurazione per client con chiave per nome autenticato, o un pool esplicito. Cambiare la prenotazione DHCP di un router LAN non crea quell’assegnazione, e aggiungere una prenotazione del tunnel non influenza la LAN. WireGuard va oltre, perché un peer è identificato dalla sua chiave pubblica e dagli indirizzi consentiti, non da un identificatore hardware. Nessuna prenotazione Ethernet generica sostituisce lì la configurazione del peer.

Tieni un inventario che separi quattro oggetti: la credenziale del dispositivo, l’adattatore virtuale, l’identificatore dell’allocatore e l’indirizzo assegnato. Una stessa macchina fisica può avere più adattatori, indirizzi e sessioni.

Un indirizzo stabile non è un’identità

Un indirizzo prevedibile è comodo sul piano operativo e non è una credenziale di autenticazione. Le regole di accesso che si basano su un indirizzo smettono di essere controlli di identità nel momento in cui viene riassegnato, condiviso o falsificato. Se una regola dipende dall’indirizzo, coordina riassegnazione e revoca con chi possiede l’identità, e tieni la vera decisione di autenticazione altrove. Così una comodità non diventa l’unica prova di quale dispositivo si è connesso.

Registra insieme l’allocatore, l’identificatore e l’indirizzo assegnato. Quando uno cambia, gli altri due sono ciò che controlli.

Se due sistemi affermano entrambi di assegnare per la stessa sottorete, decidi quale la possiede prima di aggiungere prenotazioni a uno dei due.