Il nome host del gateway Pi aggiorna da solo le rotte statiche?

Un nome DNS per il tuo gateway Pi non riscrive mai un next hop già installato. Guarda cosa memorizza il kernel e chi deve aggiornare la rotta.

Puntare una rotta statica verso un nome di gateway sembra che dovrebbe sopravvivere a un cambio di indirizzo, e non lo fa. Il nome vive nel DNS, mentre la rotta resta nella tabella di routing del client come next hop numerico. Quando il Pi si sposta su un altro indirizzo, ogni consumatore che ha già installato il vecchio hop continua a inviare traffico allo stesso numero. Nessun resolver è collegato alla tabella di inoltro, quindi nulla riscrive quella voce per te.

La risposta DNS e la rotta sono oggetti diversi

Diciamo che il tuo Pi risponde a vpn-gw.lan e inoltra 10.44.0.0/16 in un tunnel. I client su 192.168.30.0/24 lo raggiungono tramite una rotta statica. Quando l’indirizzo del Pi è passato da 192.168.30.4 a 192.168.30.11, il record ha seguito entro il suo TTL e le rotte no.

Le due viste sono in disaccordo in un modo facile da mancare, perché entrambe sembrano plausibili quando le interroghi separatamente:

$ ip route get 10.44.0.1
10.44.0.1 via 192.168.30.4 dev eth0 src 192.168.30.20
$ dig +short vpn-gw.lan
192.168.30.11

Solo la prima riga decide dove vanno i pacchetti. La seconda riga risponde a una domanda che il kernel non ha mai posto. Un record con più record A non diventa nemmeno una politica di failover, perché ogni indirizzo deve comunque essere un next hop utilizzabile su quel segmento.

Cosa resta nella tabella dopo che il comando esce

Una rotta Linux registra due cose che contano qui: il next hop come indirizzo di protocollo, e l’interfaccia di uscita come numero di indice. Gli attributi di rotta rtnetlink nominano quel primo campo RTA_GATEWAY, e contiene byte. Una volta che la voce è al suo posto, non vi è allegato alcun TTL e nessuna ricerca in background la aggiorna.

Ecco perché ip route add 10.44.0.0/16 via vpn-gw.lan può sembrare funzionare. Lo strumento risolve il nome mentre il comando è in esecuzione, scrive l’indirizzo risultante e dimentica del tutto il nome. Esegui ip route show 10.44.0.0/16 dopo e ottieni indietro un indirizzo letterale.

Vale la pena conoscere questo comportamento prima di dare la colpa al tunnel.

Strumenti che risolvono un nome per te, e quando

Alcuni router e firewall accettano davvero nomi host in un campo di rotta o di gateway. Ciò che conta è quando avviene la risoluzione. Se il dispositivo risolve il nome solo mentre applichi la configurazione, la voce memorizzata è statica quanto un indirizzo digitato, e un cambio di indirizzo successivo richiede un’altra applicazione. Il fatto che il campo accetti un nome non ti dice nulla sull’aggiornamento.

Le installazioni gestite tendono a dividere il lavoro. Una prenotazione DHCP o un lease statico mantiene il Pi su un solo indirizzo, e il record DNS segue semplicemente il lease. Nulla deve inseguire un bersaglio mobile perché il bersaglio non si muove.

Un aggiornatore monitorato è l’altro schema legittimo, e ha bisogno di un responsabile.

Fissa l’indirizzo o esegui tu stesso l’aggiornatore

Per una piccola LAN, una prenotazione sul server DHCP è la soluzione più economica. Scegli un indirizzo fuori dal pool dinamico, legalo all’indirizzo MAC del Pi e confermalo con ip -4 addr show dev eth0 dopo il prossimo rinnovo del lease. Poi punta una volta il next hop dei client a quell’indirizzo. Ora hai un gateway stabile e un record che lo descrive, ed è l’ordine in cui la relazione funziona davvero.

Se il Pi deve davvero spostarsi, tieni la riparazione della rotta in un solo posto invece di modificare a mano ogni client. Uno script breve che risolve, confronta e sostituisce basta a rendere il passo ripetibile:

new=$(dig +short vpn-gw.lan | head -n1)
cur=$(ip route get 10.44.0.1 | awk '{print $3}')
if [ "$new" != "$cur" ]; then
  ip route replace 10.44.0.0/16 via "$new"
fi
ip route get 10.44.0.1

L’ultimo comando è il test di accettazione, perché stampa il gateway che il kernel userà davvero. Se l’indirizzo stampato è ancora quello vecchio, lo script è stato eseguito nel namespace di rete sbagliato o non aveva i permessi, e il lato DNS è irrilevante.

Controlla anche il percorso di ritorno. Il Pi deve sapere come raggiungere la sottorete dei client, e il suo firewall deve consentire il traffico del tunnel. Una rotta predefinita aggiunta per coprire il disallineamento di solito nasconde il vero vuoto e rompe qualcos’altro una settimana dopo.

Articoli correlati