Werkt de hostnaam van de Pi-gateway statische routes vanzelf bij?

Een DNS-naam voor je Pi-gateway herschrijft nooit een geïnstalleerde volgende hop. Zie wat de kernel opslaat en wie de route moet bijwerken.

Een statische route naar een gateway-naam laten wijzen voelt alsof die een adreswijziging zou moeten overleven, en dat doet hij niet. De naam leeft in DNS, terwijl de route in de routingtabel van de client staat als een numerieke volgende hop. Wanneer de Pi naar een ander adres verhuist, blijft elke verbruiker die de oude hop al heeft geïnstalleerd, verkeer naar hetzelfde nummer sturen. Er is geen resolver aan de doorstuurtabel gekoppeld, dus niets herschrijft die vermelding voor je.

Het DNS-antwoord en de route zijn verschillende objecten

Stel dat je Pi antwoordt op vpn-gw.lan en 10.44.0.0/16 naar een tunnel doorstuurt. Clients op 192.168.30.0/24 bereiken hem via een statische route. Toen het adres van de Pi van 192.168.30.4 naar 192.168.30.11 verschoof, volgde het record binnen zijn TTL en de routes niet.

De twee weergaven zijn het oneens op een manier die makkelijk te missen is, want beide lijken plausibel als je ze apart opvraagt:

$ 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

Alleen de eerste regel bepaalt waar pakketten heen gaan. De tweede regel beantwoordt een vraag die de kernel nooit stelde. Een record met meerdere A-records wordt ook geen failoverbeleid, want elk adres moet nog steeds een bruikbare volgende hop op dat segment zijn.

Wat er in de tabel overblijft nadat de opdracht klaar is

Een Linux-route legt twee dingen vast die hier tellen: de volgende hop als protocoladres, en de uitgaande interface als indexnummer. De rtnetlink-routeattributen noemen dat eerste veld RTA_GATEWAY, en het bevat bytes. Zodra de vermelding op zijn plaats staat, hangt er geen TTL aan en geen enkele achtergrondzoekopdracht verfrist hem.

Daarom kan ip route add 10.44.0.0/16 via vpn-gw.lan lijken te werken. Het gereedschap lost de naam op terwijl de opdracht loopt, schrijft het resulterende adres en vergeet de naam volledig. Voer daarna ip route show 10.44.0.0/16 uit en je krijgt een letterlijk adres terug.

Dat gedrag is de moeite waard om te kennen voordat je de tunnel de schuld geeft.

Gereedschap dat een naam voor je oplost, en wanneer

Sommige routers en firewalls accepteren wel degelijk hostnamen in een route- of gatewayveld. Wat telt, is wanneer de resolutie gebeurt. Als het apparaat de naam alleen oplost terwijl je de configuratie toepast, is de opgeslagen vermelding net zo statisch als een getypt adres, en een latere adreswijziging vereist nog een toepassing. Dat het veld een naam accepteert, zegt je niets over verversing.

Beheerde opstellingen verdelen het werk meestal. Een DHCP-reservering of statische lease houdt de Pi op één adres, en het DNS-record volgt simpelweg de lease. Niets hoeft een bewegend doel te volgen, omdat het doel niet beweegt.

Een bewaakte updater is het andere legitieme patroon, en die heeft een eigenaar nodig.

Zet het adres vast of draai de updater zelf

Voor een klein LAN is een reservering op de DHCP-server de goedkoopste oplossing. Kies een adres buiten de dynamische pool, bind het aan het MAC-adres van de Pi, en bevestig het met ip -4 addr show dev eth0 na de volgende lease-vernieuwing. Daarna wijs je de volgende hop van de clients één keer naar dat adres. Je hebt nu een stabiele gateway en een record dat hem beschrijft, en dat is de volgorde waarin de relatie echt werkt.

Als de Pi echt moet verhuizen, houd de routereparatie dan op één plek in plaats van elke client met de hand te bewerken. Een kort script dat oplost, vergelijkt en vervangt is genoeg om de stap herhaalbaar te maken:

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

De laatste opdracht is de acceptatietest, want die drukt de gateway af die de kernel echt gaat gebruiken. Als het afgedrukte adres nog het oude is, liep het script in de verkeerde netwerknaamruimte of had het geen toestemming, en de DNS-kant is irrelevant.

Controleer ook de terugweg. De Pi moet weten hoe hij het clientsubnet bereikt, en zijn firewall moet het tunnelverkeer toestaan. Een standaardroute die wordt toegevoegd om de mismatch te verbergen, verbergt meestal het echte gat en breekt een week later iets anders.

Gerelateerde artikelen