Uppdaterar Pi-gatewayens värdnamn statiska rutter av sig själv?

Ett DNS-namn för din Pi-gateway skriver aldrig om en installerad nästa hopp. Se vad kärnan lagrar och vem som måste uppdatera rutten.

Att peka en statisk rutt mot ett gateway-namn känns som något som borde överleva en adressändring, och det gör det inte. Namnet bor i DNS, medan rutten sitter i klientens routingtabell som en numerisk nästa hopp. När Pi:n flyttar till en annan adress fortsätter varje konsument som redan installerat det gamla hoppet att skicka trafik till samma nummer. Ingen resolver är kopplad till vidarebefordringstabellen, så ingenting skriver om den posten åt dig.

DNS-svaret och rutten är olika objekt

Säg att din Pi svarar på vpn-gw.lan och vidarebefordrar 10.44.0.0/16 in i en tunnel. Klienter på 192.168.30.0/24 når den via en statisk rutt. När Pi:ns adress flyttade från 192.168.30.4 till 192.168.30.11 följde posten med inom sin TTL, och rutterna gjorde det inte.

De två vyerna är oense på ett sätt som är lätt att missa, eftersom båda verkar rimliga när man frågar dem var för sig:

$ 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

Bara den första raden avgör vart paketen tar vägen. Den andra raden svarar på en fråga som kärnan aldrig ställde. En post med flera A-poster blir inte heller en failover-policy, eftersom varje adress fortfarande måste vara ett användbart nästa hopp på det segmentet.

Vad som blir kvar i tabellen när kommandot har avslutats

En Linux-rutt registrerar två saker som spelar roll här: nästa hopp som protokolladress, och utgångsgränssnittet som ett indexnummer. rtnetlink-ruttattributen namnger det första fältet RTA_GATEWAY, och det innehåller byte. När posten väl är på plats finns ingen TTL kopplad till den, och ingen bakgrundsuppslagning uppdaterar den.

Det är därför ip route add 10.44.0.0/16 via vpn-gw.lan kan se ut att fungera. Verktyget löser namnet medan kommandot körs, skriver den resulterande adressen och glömmer namnet helt. Kör ip route show 10.44.0.0/16 efteråt och du får tillbaka en bokstavlig adress.

Det beteendet är värt att känna till innan du skyller på tunneln.

Verktyg som löser ett namn åt dig, och när

Vissa routrar och brandväggar accepterar faktiskt värdnamn i ett rutt- eller gateway-fält. Det viktiga är när uppslagningen sker. Om enheten bara löser namnet medan du tillämpar konfigurationen är den lagrade posten lika statisk som en skriven adress, och en senare adressändring kräver ännu en tillämpning. Att fältet accepterar ett namn säger dig ingenting om uppdatering.

Hanterade installationer brukar dela upp arbetet. En DHCP-reservation eller statisk lease håller Pi:n på en adress, och DNS-posten följer helt enkelt leasen. Ingenting behöver följa ett rörligt mål eftersom målet inte rör sig.

En övervakad uppdaterare är det andra legitima mönstret, och den behöver en ägare.

Fäst adressen eller kör uppdateraren själv

För ett litet LAN är en reservation på DHCP-servern den billigaste lösningen. Välj en adress utanför den dynamiska poolen, bind den till Pi:ns MAC-adress och bekräfta den med ip -4 addr show dev eth0 efter nästa lease-förnyelse. Sedan peka klienternas nästa hopp mot den adressen en gång. Nu har du en stabil gateway och en post som beskriver den, och det är den ordning som förhållandet faktiskt fungerar i.

Om Pi:n verkligen måste flytta, håll ruttlagningen på ett ställe i stället för att redigera varje klient för hand. Ett kort skript som löser, jämför och ersätter räcker för att göra steget repeterbart:

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

Det sista kommandot är acceptanstestet, eftersom det skriver ut den gateway som kärnan faktiskt kommer att använda. Om den utskrivna adressen fortfarande är den gamla körde skriptet i fel nätverksnamnrymd eller saknade behörighet, och DNS-sidan är irrelevant.

Kontrollera returvägen också. Pi:n måste veta hur den når klienternas subnät, och dess brandvägg måste tillåta tunneltrafiken. En standardrutt som läggs till för att dölja missförhållandet gömmer oftast den verkliga luckan och förstör något annat en vecka senare.

Relaterade artiklar