Ĉu gastnomo de la Pi-pordego mem ĝisdatigas statikajn vojojn?

Montri statikan vojon al pordega nomo sentiĝas kvazaŭ ĝi devus postvivi adresŝanĝon, kaj ĝi ne faras tion. La nomo vivas en DNS, dum la vojo sidas en la enkursiga tabelo de la kliento kiel nombra sekva salteto. Kiam la Pi transloĝiĝas al alia adreso, ĉiu konsumanto, kiu jam instalas la malnovan salteton, daŭre sendas trafikon al la sama nombro. Neniu solvilo estas kablita al la plusenda tabelo, do nenio reskribas tiun enskribon por vi.

La DNS-respondo kaj la vojo estas malsamaj objektoj

Supozu, ke via Pi respondas al vpn-gw.lan kaj plusendas 10.44.0.0/16 en tunelon. Klientoj en 192.168.30.0/24 atingas ĝin per statika vojo. Kiam la adreso de la Pi moviĝis de 192.168.30.4 al 192.168.30.11, la rikordo sekvis ene de sia TTL kaj la vojoj ne.

La du vidpunktoj malkongruas tiel, ke facile maltrafeblas, ĉar ambaŭ aspektas kredindaj, kiam vi demandas ilin aparte:

$ 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

Nur la unua linio decidas, kien la pakaĵoj iras. La dua linio respondas demandon, kiun la kerno neniam faris. Rikordo kun pluraj A-rikordoj ankaŭ ne fariĝas malsukcesa transiga politiko, ĉar ĉiu adreso ankoraŭ devas esti uzebla sekva salteto en tiu segmento.

Kio restas en la tabelo post kiam la komando finiĝas

Linux-vojo registras du aferojn, kiuj gravas ĉi tie: la sekvan salteton kiel protokolan adreson, kaj la eligan interfacon kiel indeksan nombron. La rtnetlink-vojaj atributoj nomas tiun unuan kampon RTA_GATEWAY, kaj ĝi tenas bajtojn. Post kiam la enskribo estas en loko, neniu TTL estas alligita al ĝi kaj neniu fona serĉado ĝisdatigas ĝin.

Jen kial ip route add 10.44.0.0/16 via vpn-gw.lan povas ŝajni funkcii. La ilo solvas la nomon dum la komando funkcias, skribas la rezultan adreson kaj tute forgesas la nomon. Rulu ip route show 10.44.0.0/16 poste kaj vi rericevos laŭvortan adreson.

Tiu konduto indas koniĝi antaŭ ol vi kulpas la tunelon.

Iloj, kiuj solvas nomon por vi, kaj kiam

Iuj enkursigiloj kaj fajroŝirmiloj ja akceptas gastnomojn en voja aŭ pordega kampo. Gravas, kiam la solvado okazas. Se la aparato solvas la nomon nur dum vi aplikas la agordon, la konservita enskribo estas same statika kiel tajpita adreso, kaj posta adresŝanĝo bezonas plian aplikadon. Tio, ke la kampo akceptas nomon, diras al vi nenion pri ĝisdatigo.

Administrataj agordoj emas dividi la laboron. DHCP-rezervo aŭ statika luo tenas la Pi-n sur unu adreso, kaj la DNS-rikordo simple sekvas la luon. Nenio devas spuri moviĝantan celon, ĉar la celo ne moviĝas.

Observata ĝisdatigilo estas la alia laŭleĝa ŝablono, kaj ĝi bezonas posedanton.

Fiksu la adreson aŭ mem rulu la ĝisdatigilon

Por malgranda LAN, rezervo sur la DHCP-servilo estas la plej malmultekosta solvo. Elektu adreson ekster la dinamika provizo, ligu ĝin al la MAC-adreso de la Pi, kaj konfirmu ĝin per ip -4 addr show dev eth0 post la sekva luorenovigo. Poste turnu la sekvan salteton de la klientoj al tiu adreso unufoje. Nun vi havas stabilan pordegon kaj rikordon, kiu priskribas ĝin, kaj tio estas la ordo, en kiu la rilato efektive funkcias.

Se la Pi vere devas moviĝi, tenu la vojriparon en unu loko anstataŭ permane redakti ĉiun klienton. Mallonga skripto, kiu solvas, komparas kaj anstataŭas, sufiĉas por igi la paŝon ripetebla:

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

La lasta komando estas la akcepta testo, ĉar ĝi presas la pordegon, kiun la kerno efektive uzos. Se la presita adreso estas ankoraŭ la malnova, la skripto ruliĝis en malĝusta reta nomspaco aŭ mankis permeso, kaj la DNS-flanko estas nerelevanta.

Kontrolu ankaŭ la revenan vojon. La Pi devas scii, kiel atingi la klientan subreton, kaj ĝia fajroŝirmilo devas permesi la tunelan trafikon. Defaŭlta vojo aldonita por kovri la malkongruon kutime kaŝas la veran breĉon kaj rompas ion alian semajnon poste.