El nom d'amfitrió de la passarel·la Pi actualitza sol les rutes estàtiques?

Un nom DNS per a la vostra passarel·la Pi no reescriu mai un salt següent instal·lat. Mireu què desa el nucli i qui ha d'actualitzar la ruta.

Apuntar una ruta estàtica cap a un nom de passarel·la sembla que hauria de sobreviure a un canvi d'adreça, i no ho fa. El nom viu al DNS, mentre que la ruta se seu a la taula d'encaminament del client com un salt següent numèric. Quan la Pi es mou a una altra adreça, cada consumidor que ja va instal·lar el salt vell continua enviant trànsit al mateix número. Cap resolutor no està connectat a la taula de reenviament, així que res no reescriu aquesta entrada per vosaltres.

La resposta DNS i la ruta són objectes diferents

Diguem que la vostra Pi respon a vpn-gw.lan i reenvia 10.44.0.0/16 cap a un túnel. Els clients de 192.168.30.0/24 hi arriben mitjançant una ruta estàtica. Quan l'adreça de la Pi va passar de 192.168.30.4 a 192.168.30.11, el registre va seguir dins del seu TTL i les rutes no.

Les dues vistes no coincideixen d'una manera fàcil de passar per alt, perquè totes dues semblen plausibles quan les consulteu per separat:

$ 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

Només la primera línia decideix on van els paquets. La segona línia respon una pregunta que el nucli mai no va fer. Un registre amb diversos registres A tampoc no es converteix en una política de commutació per error, ja que cada adreça encara ha de ser un salt següent viable en aquell segment.

Què sobreviu a la taula després que surti l'ordre

Una ruta de Linux enregistra dues coses que importen aquí: el salt següent com a adreça de protocol, i la interfície de sortida com a número d'índex. Els atributs de ruta de rtnetlink anomenen aquest primer camp RTA_GATEWAY, i conté bytes. Un cop l'entrada és al seu lloc, no hi ha cap TTL adjunt i cap cerca en segon pla no l'actualitza.

Per això ip route add 10.44.0.0/16 via vpn-gw.lan pot semblar que funciona. L'eina resol el nom mentre s'executa l'ordre, escriu l'adreça resultant i oblida el nom completament. Executeu ip route show 10.44.0.0/16 després i obtindreu una adreça literal.

Val la pena conèixer aquest comportament abans de culpar el túnel.

Eines que us resolen un nom, i quan

Alguns routers i tallafocs sí que accepten noms d'amfitrió en un camp de ruta o de passarel·la. L'important és quan es fa la resolució. Si el dispositiu només resol el nom mentre apliqueu la configuració, l'entrada desada és tan estàtica com una adreça escrita, i un canvi d'adreça posterior necessita una altra aplicació. Que el camp accepti un nom no us diu res sobre l'actualització.

Els entorns gestionats solen dividir la feina. Una reserva DHCP o un arrendament estàtic manté la Pi en una adreça, i el registre DNS simplement segueix l'arrendament. No cal fer el seguiment d'un objectiu mòbil perquè l'objectiu no es mou.

Un actualitzador monitorat és l'altre patró legítim, i necessita un responsable.

Fixeu l'adreça o executeu l'actualitzador vosaltres mateixos

Per a una LAN petita, una reserva al servidor DHCP és la solució més barata. Trieu una adreça fora del pool dinàmic, lligueu-la a l'adreça MAC de la Pi i confirmeu-ho amb ip -4 addr show dev eth0 després de la propera renovació de l'arrendament. Aleshores apunteu el salt següent dels clients a aquesta adreça una vegada. Ara teniu una passarel·la estable i un registre que la descriu, que és l'ordre en què la relació funciona realment.

Si la Pi s'ha de moure de debò, manteniu la reparació de la ruta en un sol lloc en lloc d'editar cada client a mà. Un script curt que resolgui, compari i substitueixi n'hi ha prou per fer el pas repetible:

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'última ordre és la prova d'acceptació, perquè imprimeix la passarel·la que el nucli farà servir realment. Si l'adreça impresa encara és la vella, el script s'ha executat en un espai de noms de xarxa equivocat o no tenia permisos, i el costat DNS és irrellevant.

Comproveu també el camí de tornada. La Pi ha de saber com arribar a la subxarxa dels clients, i el seu tallafocs ha de permetre el trànsit del túnel. Una ruta per defecte afegida per tapar el desajust sol amagar el buit real i trenca una altra cosa una setmana després.

Articles relacionats