Oppdaterer vertsnamnet til Pi-gatewayen statiske ruter av seg sjølv?

Eit DNS-namn for Pi-gatewayen din skriv aldri om ein installert neste hopp. Sjå kva kjernen lagrar, og kven som må oppdatere ruta.

Å peike ei statisk rute mot eit gateway-namn kjennest som noko som burde tole ei adresseendring, og det gjer det ikkje. Namnet bur i DNS, medan ruta sit i rutetabellen til klienten som eit numerisk neste hopp. Når Pi-en flyttar til ei anna adresse, held kvar forbrukar som alt har installert den gamle hoppet, fram med å sende trafikk til same nummer. Ingen resolvar er kopla til vidaresendingstabellen, så ingenting skriv om den oppføringa for deg.

DNS-svaret og ruta er ulike objekt

La oss seie at Pi-en din svarar på vpn-gw.lan og vidaresender 10.44.0.0/16 inn i ein tunnel. Klientar på 192.168.30.0/24 når han via ei statisk rute. Då adressa til Pi-en flytta frå 192.168.30.4 til 192.168.30.11, følgde oppføringa med innanfor sin TTL, og rutene gjorde det ikkje.

Dei to visingane er usamde på ein måte som er lett å oversjå, fordi begge verkar rimelege når du spør dei kvar 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

Berre den første linja avgjer kvar pakkane går. Den andre linja svarar på eit spørsmål kjernen aldri stilte. Ei oppføring med fleire A-oppføringar vert heller ikkje ein failover-policy, fordi kvar adresse framleis må vere eit brukbart neste hopp på det segmentet.

Kva som vert att i tabellen etter at kommandoen er ferdig

Ei Linux-rute registrerer to ting som betyr noko her: neste hopp som protokolladresse, og utgangsgrensesnittet som eit indeksnummer. rtnetlink-ruteattributta namngjev det første feltet RTA_GATEWAY, og det inneheld bytes. Når oppføringa først er på plass, er ingen TTL knytt til henne, og ingen bakgrunnsoppslag oppdaterer henne.

Det er difor ip route add 10.44.0.0/16 via vpn-gw.lan kan sjå ut til å verke. Verktøyet løyser namnet medan kommandoen køyrer, skriv den resulterande adressa og gløymer namnet heilt. Køyr ip route show 10.44.0.0/16 etterpå, og du får ei bokstaveleg adresse tilbake.

Den åtferda er verdt å kjenne før du gir tunnelen skulda.

Verktøy som løyser eit namn for deg, og når

Nokre rutarar og brannmurar godtek faktisk vertsnamn i eit rute- eller gateway-felt. Det viktige er når oppslaget skjer. Viss eininga berre løyser namnet medan du brukar konfigurasjonen, er den lagra oppføringa like statisk som ei skriven adresse, og ei seinare adresseendring krev nok ein bruk. At feltet godtek eit namn, seier deg ingenting om oppdatering.

Styrte oppsett deler vanlegvis jobben. Ein DHCP-reservasjon eller statisk lease held Pi-en på éi adresse, og DNS-oppføringa følgjer ganske enkelt leasen. Ingenting må følgje eit flyttande mål, fordi målet flyttar seg ikkje.

Ein overvaka oppdaterar er det andre legitime mønsteret, og det treng ein eigar.

Fest adressa eller køyr oppdateraren sjølv

For eit lite LAN er ein reservasjon på DHCP-tenaren den billegaste løysinga. Vel ei adresse utanfor den dynamiske poolen, bind henne til MAC-adressa til Pi-en, og stadfest henne med ip -4 addr show dev eth0 etter neste lease-fornying. Deretter peik neste hopp for klientane mot den adressa éin gong. No har du ein stabil gateway og ei oppføring som skildrar han, og det er rekkjefølgja forholdet faktisk verkar i.

Viss Pi-en verkeleg må flytte, hald rutereparasjonen på éin stad i staden for å redigere kvar klient for hand. Eit kort skript som løyser, samanliknar og erstattar er nok til å gjere 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 han skriv ut gatewayen kjernen faktisk vil bruke. Viss den utskrivne adressa framleis er den gamle, køyrde skriptet i feil nettverksnamnerom eller mangla løyve, og DNS-sida er irrelevant.

Sjekk returvegen òg. Pi-en må vite korleis han når klientens subnett, og brannmuren må tillate tunneltrafikken. Ei standardrute som vert lagd til for å dekkje over misforholdet, skjuler vanlegvis det eigentlege gapet og øydelegg noko anna ei veke seinare.

Relaterte artiklar