169.254 attraverso una VPN: l~indirizzo non è mai stato instradabile
Una destinazione link-local viene scartata prima di raggiungere il tunnel, quindi aggiungere route non fa che allargare il guasto. Scegli tra riparare la sottorete e creare un bridge.
Aggiungi la route, il tunnel sale, eppure il ping verso l’altro lato muore con perdita totale invece che con «network unreachable». La differenza conta, perché sposta l’attenzione dalla tabella di routing all’indirizzo stesso. Una destinazione 169.254 è link-local, e il suo ambito termina al primo hop per progetto, non per configurazione errata.
La decisione che segue è stretta e va presa esplicitamente: riparare la sottorete lato server, oppure estendere il segmento di livello 2 perché l’indirizzo torni ad avere senso locale. Tutto il resto, compresa una route più ampia, non fa che applicare lo stesso guasto a più destinazioni.
L’indirizzo non è senza route: è non instradabile
Gli indirizzi IPv4 link-local si assegnano da soli quando nulla di meglio risponde; da qui nasce l’indirizzamento privato automatico di Windows e l’equivalente degli altri sistemi. L’intervallo è in uso su ogni collegamento contemporaneamente, ed è proprio per questo che funziona: due host nello stesso segmento parlano senza alcun coordinamento.
È la stessa proprietà a impedire a un router di inoltrare questi pacchetti tra reti. Ricevere un pacchetto destinato a un indirizzo link-local e farlo uscire da un’altra interfaccia creerebbe ambiguità, perché il «locale» del mittente e il «locale» del destinatario sono luoghi diversi. Nessuna ricerca può stabilire quale dei due intendesse il mittente. L’inoltro qui non è un’opzione di policy che un amministratore possa attivare; la classe di indirizzi lo esclude.
Quindi un gateway che installa 169.254.1.10 come raggiungibile dal tunnel chiede al kernel qualcosa che il formato dell’indirizzo vieta. Il pacchetto viene scartato molto prima di raggiungere l’host remoto, e nessuna precisione di route cambia l’esito.
Perché un tunnel rende visibile il problema di ambito
Un’interfaccia TUN trasporta pacchetti IP tra due pari e non ha alcun segmento condiviso alle spalle. Non c’è broadcast, non c’è ARP per l’altro lato, e non c’è scoperta dei vicini che possa risolvere una destinazione link-local in un indirizzo di livello collegamento.
I sintomi combaciano appena sai cosa cercare. La route è nella tabella, il ping riporta perdita totale invece di rete irraggiungibile, e la tabella dei vicini mostra una voce incompleta o fallita. Una cattura sul tunnel mostra il pacchetto uscire, il che spinge a guardare l’estremo remoto invece della classe di indirizzo.
Su Windows c’è un secondo sintomo, in apparenza non correlato, con la stessa radice: un adattatore rimasto con il solo indirizzo link-local non ha un gateway utilizzabile, quindi l’identificazione di rete non riesce a classificare la connessione e il profilo del firewall finisce su pubblico. Il tunnel non è la causa; l’indirizzo lo è.
Decidi con tre domande
La scelta tra riparare la sottorete e collegare in bridge il link dipende da tre condizioni, e ciascuna può risolverla prima ancora di aprire un file di configurazione.
| Question | If yes | If no |
|---|---|---|
| Can the far-side host be given a routable address? | Change the host or fix DHCP and route normally | Continue to the next question |
| Does the device accept a static address at all? | Assign one from the site's real prefix | Bridging is the only remaining option |
| Can you accept broadcast crossing the tunnel? | A bridge is viable for a small segment | Replace the device or accept no remote access |
La maggior parte dei casi si ferma alla prima domanda. Un host con indirizzo link-local di solito significa che il DHCP non ha risposto, che un cavo o una VLAN sono sbagliati, o che qualcuno ha scritto l’indirizzo a mano. Ripararlo costa meno di qualsiasi lavoro sul tunnel e toglie il problema a ogni client futuro, non solo a questo.
Controlla il lato server prima di dare qualcosa per scontato. Esegui ip addr show e ip route sull’host, e arp -n o route print -4 sul client, per vedere se il prefisso esiste o se lo afferma solo una voce vecchia.
Quanto costa un bridge quando è la risposta giusta
Collegare in bridge un adattatore fisico con un adattatore TAP rende il client remoto parte del dominio di broadcast locale. Allora broadcast e scoperta dei vicini funzionano, e un indirizzo link-local torna ad avere senso perché il client è davvero locale su quel collegamento.
I costi sono reali e vanno detti prima che qualcuno accetti. Il traffico di broadcast attraversa il tunnel, il client è esposto al segmento locale per ogni scopo e non solo ai servizi che gli servono, e il server ora deve inoltrare frame invece di instradare pacchetti. È uno scambio ragionevole per un banco di laboratorio o un dispositivo senza percorso di configurazione instradabile, e un brutto valore predefinito per l’accesso remoto.
Quando fai il bridge servono entrambe le metà: il bridge sul server e una route nel profilo del client che dica quali destinazioni stanno dall’altra parte. Il solo bridge lascia il client a indovinare, e la sola route non sistema una classe di indirizzo.