Oppdaterer vertsnavnet til Pi-gatewayen statiske ruter av seg selv?
Et DNS-navn for Pi-gatewayen din skriver aldri om en installert neste hopp. Se hva kjernen lagrer, og hvem som må oppdatere ruten.
Å peke en statisk rute mot et gateway-navn føles som noe som burde tåle en adresseendring, og det gjør det ikke. Navnet bor i DNS, mens ruten sitter i klientens rutetabell som en numerisk neste hopp. Når Pi-en flytter til en annen adresse, fortsetter hver forbruker som allerede har installert den gamle hoppet, å sende trafikk til samme nummer. Ingen resolver er koblet til videresendingstabellen, så ingenting skriver om den oppføringen for deg.
DNS-svaret og ruten er forskjellige objekter
La oss si at Pi-en din svarer på vpn-gw.lan og videresender 10.44.0.0/16 inn i en tunnel. Klienter på 192.168.30.0/24 når den via en statisk rute. Da adressen til Pi-en flyttet fra 192.168.30.4 til 192.168.30.11, fulgte oppføringen med innenfor sin TTL, og rutene gjorde ikke.
De to visningene er uenige på en måte som er lett å overse, fordi begge virker rimelige når du spør dem hver for seg:
$ 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
Bare den første linjen avgjør hvor pakkene går. Den andre linjen svarer på et spørsmål kjernen aldri stilte. En oppføring med flere A-oppføringer blir heller ikke en failover-policy, fordi hver adresse fortsatt må være en brukbar neste hopp på det segmentet.
Hva som blir igjen i tabellen etter at kommandoen er ferdig
En Linux-rute registrerer to ting som betyr noe her: neste hopp som protokolladresse, og utgangsgrensesnittet som et indeksnummer. rtnetlink-ruteattributtene navngir det første feltet RTA_GATEWAY, og det inneholder bytes. Når oppføringen først er på plass, er ingen TTL knyttet til den, og ingen bakgrunnsoppslag oppdaterer den.
Det er derfor ip route add 10.44.0.0/16 via vpn-gw.lan kan se ut til å virke. Verktøyet løser navnet mens kommandoen kjører, skriver den resulterende adressen og glemmer navnet helt. Kjør ip route show 10.44.0.0/16 etterpå, og du får en bokstavelig adresse tilbake.
Den oppførselen er verdt å kjenne før du gir tunnelen skylden.
Verktøy som løser et navn for deg, og når
Noen rutere og brannmurer godtar faktisk vertsnavn i et rute- eller gateway-felt. Det viktige er når oppslaget skjer. Hvis enheten bare løser navnet mens du bruker konfigurasjonen, er den lagrede oppføringen like statisk som en skrevet adresse, og en senere adresseendring krever nok en bruk. At feltet godtar et navn, sier deg ingenting om oppdatering.
Administrerte oppsett deler vanligvis jobben. En DHCP-reservasjon eller statisk lease holder Pi-en på én adresse, og DNS-oppføringen følger ganske enkelt leasen. Ingenting må følge et flyttende mål, fordi målet ikke flytter seg.
En overvåket oppdaterer er det andre legitime mønsteret, og det trenger en eier.
Fest adressen eller kjør oppdatereren selv
For et lite LAN er en reservasjon på DHCP-serveren den billigste løsningen. Velg en adresse utenfor den dynamiske poolen, bind den til MAC-adressen til Pi-en, og bekreft den med ip -4 addr show dev eth0 etter neste lease-fornyelse. Deretter pek klientenes neste hopp mot den adressen én gang. Nå har du en stabil gateway og en oppføring som beskriver den, og det er rekkefølgen forholdet faktisk virker i.
Hvis Pi-en virkelig må flytte, hold rutereparasjonen på ett sted i stedet for å redigere hver klient for hånd. Et kort skript som løser, sammenligner og erstatter er nok til å gjøre trinnet 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
Den siste kommandoen er aksepttesten, fordi den skriver ut gatewayen kjernen faktisk vil bruke. Hvis den utskrevne adressen fortsatt er den gamle, kjørte skriptet i feil nettverksnavnerom eller manglet tillatelse, og DNS-siden er irrelevant.
Sjekk returveien også. Pi-en må vite hvordan den når klientens subnett, og brannmuren må tillate tunneltrafikken. En standardrute som legges til for å dekke over misforholdet, skjuler vanligvis det egentlige gapet og ødelegger noe annet en uke senere.