Magától frissíti a Pi-átjáró gazdagépneve a statikus útvonalakat?

A Pi-átjáró DNS-neve soha nem írja át a telepített következő ugrást. Nézze meg, mit tárol a kernel, és kinek kell frissítenie az útvonalat.

Ha egy statikus útvonalat átjárónévre irányítunk, az úgy tűnik, mintha túl kellene élnie egy címváltozást, pedig nem éli túl. A név a DNS-ben él, míg az útvonal numerikus következő ugrásként ül a kliens útválasztási táblázatában. Amikor a Pi más címre költözik, minden fogyasztó, amely már telepítette a régi ugrást, továbbra is ugyanarra a számra küld forgalmat. Egyetlen feloldó sincs bekötve a továbbítási táblázatba, így semmi nem írja át azt a bejegyzést ön helyett.

A DNS-válasz és az útvonal különböző objektumok

Tegyük fel, hogy a Pi a vpn-gw.lan névre válaszol, és a 10.44.0.0/16 hálózatot egy alagútba továbbítja. Az 192.168.30.0/24 hálózaton lévő kliensek statikus útvonalon érik el. Amikor a Pi címe 192.168.30.4-ről 192.168.30.11-re változott, a rekord a TTL-jén belül követte, az útvonalak viszont nem.

A két nézet olyan módon mond ellent egymásnak, amelyet könnyű elnézni, mert külön-külön kérdezve mindkettő hihetőnek tűnik:

$ 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

Csak az első sor dönti el, hová mennek a csomagok. A második sor egy olyan kérdésre válaszol, amelyet a kernel soha nem tett fel. A több A-rekordot tartalmazó rekord sem válik hibafallback-szabályzattá, mert minden címnek továbbra is használható következő ugrásnak kell lennie azon a szakaszon.

Mi marad a táblázatban, miután a parancs kilép

A Linux útvonal két dolgot rögzít, amelyek itt számítanak: a következő ugrást protokollcímként, és a kimenő interfészt indexszámként. A rtnetlink útvonal-attribútumok nevezik meg azt az első mezőt RTA_GATEWAY néven, és bájtokat tartalmaz. Amint a bejegyzés a helyére kerül, nincs hozzá TTL csatolva, és semmilyen háttérkeresés nem frissíti.

Ezért tűnhet úgy, hogy a ip route add 10.44.0.0/16 via vpn-gw.lan működik. Az eszköz feloldja a nevet a parancs futása alatt, kiírja a kapott címet, és teljesen elfelejti a nevet. Futtassa utána a ip route show 10.44.0.0/16 parancsot, és szó szerinti címet kap vissza.

Érdemes ismerni ezt a viselkedést, mielőtt az alagutat hibáztatja.

Eszközök, amelyek helyetted oldanak fel egy nevet, és mikor

Egyes routerek és tűzfalak valóban elfogadnak gazdagépneveket egy útvonal- vagy átjárómezőben. Az számít, hogy mikor történik a feloldás. Ha az eszköz csak a konfiguráció alkalmazása közben oldja fel a nevet, a tárolt bejegyzés ugyanolyan statikus, mint egy beírt cím, és egy későbbi címváltozáshoz újabb alkalmazás kell. Az, hogy a mező elfogad egy nevet, semmit nem mond a frissítésről.

A kezelt környezetek általában felosztják a munkát. Egy DHCP-foglalás vagy statikus bérlet egy címen tartja a Pi-t, és a DNS-rekord egyszerűen követi a bérletet. Semminek nem kell mozgó célpontot követnie, mert a célpont nem mozog.

A felügyelt frissítő a másik legitim minta, és tulajdonosra van szüksége.

Rögzítse a címet, vagy futtassa saját maga a frissítőt

Egy kis LAN esetében a DHCP-kiszolgálón lévő foglalás a legolcsóbb megoldás. Válasszon a dinamikus készleten kívüli címet, kösse a Pi MAC-címéhez, és erősítse meg ip -4 addr show dev eth0 segítségével a következő bérlet-megújítás után. Utána irányítsa a kliensek következő ugrását egyszer erre a címre. Most van egy stabil átjárója és egy rekord, amely leírja, és ez az a sorrend, amelyben a kapcsolat valóban működik.

Ha a Pi-nek tényleg költöznie kell, tartsa az útvonaljavítást egy helyen, ahelyett hogy minden klienst kézzel szerkesztene. Egy rövid szkript, amely felold, összehasonlít és helyettesít, elég ahhoz, hogy a lépés megismételhető legyen:

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

Az utolsó parancs az elfogadási teszt, mert kiírja azt az átjárót, amelyet a kernel ténylegesen használni fog. Ha a kiírt cím még mindig a régi, a szkript rossz hálózati névtérben futott, vagy nem volt jogosultsága, a DNS-oldal pedig lényegtelen.

Ellenőrizze a visszautat is. A Pi-nek tudnia kell, hogyan érje el a kliens alhálózatot, és a tűzfalának engedélyeznie kell az alagút forgalmát. Az eltérés elfedésére hozzáadott alapértelmezett útvonal általában elrejti a valódi hiányt, és egy hét múlva mást tör el.

Kapcsolódó cikkek