Opdaterer et værtsnavn til Pi-gatewayen statiske ruter af sig selv?

Et DNS-navn til din Pi-gateway omskriver aldrig et installeret næste hop. Se hvad kernen gemmer, og hvem der skal opdatere ruten.

At pege en statisk rute mod et gateway-navn føles som noget, der burde overleve en adresseændring, og det gør det ikke. Navnet bor i DNS, mens ruten sidder i klientens routingtabel som et numerisk næste hop. Når Pi'en flytter til en anden adresse, bliver hver forbruger, der allerede har installeret det gamle hop, ved med at sende trafik til det samme nummer. Ingen resolver er forbundet med videresendingstabellen, så intet omskriver den post for dig.

DNS-svaret og ruten er forskellige objekter

Sig at din Pi svarer på vpn-gw.lan og videresender 10.44.0.0/16 ind i en tunnel. Klienter på 192.168.30.0/24 når den via en statisk rute. Da Pi'ens adresse flyttede fra 192.168.30.4 til 192.168.30.11, fulgte posten med inden for sin TTL, og ruterne gjorde ikke.

De to billeder er uenige på en måde, der er let at overse, fordi begge ser rimelige ud, når man spørger dem hver for 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

Kun den første linje bestemmer, hvor pakkerne går hen. Den anden linje svarer på et spørgsmål, som kernen aldrig stillede. En post med flere A-poster bliver heller ikke en failover-politik, fordi hver adresse stadig skal være et brugbart næste hop på det segment.

Hvad der bliver tilbage i tabellen, når kommandoen er afsluttet

En Linux-rute gemmer to ting, der betyder noget her: næste hop som en protokoladresse og udgangsgrænsefladen som et indeksnummer. rtnetlink-ruteattributterne navngiver det første felt RTA_GATEWAY, og det indeholder bytes. Når posten først er på plads, er der ingen TTL knyttet til den, og intet baggrundsopslag opdaterer den.

Det er derfor ip route add 10.44.0.0/16 via vpn-gw.lan kan se ud til at virke. Værktøjet slår navnet op, mens kommandoen kører, skriver den resulterende adresse og glemmer navnet helt. Kør ip route show 10.44.0.0/16 bagefter, og du får en bogstavelig adresse tilbage.

Den adfærd er værd at kende, før du giver tunnelen skylden.

Værktøjer, der slår et navn op for dig, og hvornår

Nogle routere og firewalls accepterer faktisk værtsnavne i et rute- eller gateway-felt. Det afgørende er, hvornår opløsningen sker. Hvis enheden kun slår navnet op, mens du anvender konfigurationen, er den gemte post lige så statisk som en indtastet adresse, og en senere adresseændring kræver endnu en anvendelse. At feltet accepterer et navn siger intet om opdatering.

Administrerede opsætninger deler ofte arbejdet. En DHCP-reservation eller statisk lease holder Pi'en på én adresse, og DNS-posten følger blot leasen. Intet skal følge et flyttende mål, fordi målet ikke flytter sig.

En overvåget opdaterer er det andet legitime mønster, og den har brug for en ejer.

Fastlås adressen, eller kør opdateringen selv

Til et lille LAN er en reservation på DHCP-serveren den billigste løsning. Vælg en adresse uden for den dynamiske pulje, bind den til Pi'ens MAC-adresse, og bekræft den med ip -4 addr show dev eth0 efter den næste leasefornyelse. Derefter peg klienternes næste hop på den adresse én gang. Nu har du en stabil gateway og en post, der beskriver den, og det er den rækkefølge, forholdet faktisk virker i.

Hvis Pi'en virkelig skal flytte, så hold rutereparationen på ét sted i stedet for at redigere hver klient i hånden. Et kort script, der slår op, sammenligner og erstatter, er nok til at gøre trinnet gentageligt:

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

Den sidste kommando er accepttesten, fordi den udskriver den gateway, som kernen faktisk vil bruge. Hvis den udskrevne adresse stadig er den gamle, kørte scriptet i det forkerte netværksnavnerum eller manglede tilladelse, og DNS-siden er irrelevant.

Tjek også returvejen. Pi'en skal vide, hvordan den når klientundernettet, og dens firewall skal tillade tunnelens trafik. En standardrute, der tilføjes for at dække over uoverensstemmelsen, skjuler normalt det egentlige hul og ødelægger noget andet en uge senere.

Relaterede artikler