Czy nazwa hosta bramy Pi sama aktualizuje trasy statyczne?

Wskazanie trasy statycznej na nazwę bramy wygląda tak, jakby miało przetrwać zmianę adresu, a nie przetrwa. Nazwa żyje w DNS, a trasa siedzi w tablicy routingu klienta jako liczbowy następny skok. Gdy Pi przenosi się na inny adres, każdy konsument, który już zainstalował stary skok, nadal wysyła ruch na ten sam numer. Żaden resolver nie jest podłączony do tablicy przekazywania, więc nic nie przepisze tego wpisu za ciebie.

Odpowiedź DNS i trasa to różne obiekty

Załóżmy, że twój Pi odpowiada na vpn-gw.lan i przekazuje 10.44.0.0/16 do tunelu. Klienci w 192.168.30.0/24 docierają do niego przez trasę statyczną. Gdy adres Pi zmienił się z 192.168.30.4 na 192.168.30.11, rekord podążył w granicach swojego TTL, a trasy nie.

Oba widoki nie zgadzają się w sposób łatwy do przeoczenia, bo oba wyglądają wiarygodnie, gdy pyta się o nie osobno:

$ 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

Tylko pierwszy wiersz decyduje, dokąd idą pakiety. Drugi wiersz odpowiada na pytanie, którego jądro nigdy nie zadało. Wpis z kilkoma rekordami A też nie staje się polityką przełączania przy awarii, bo każdy adres nadal musi być użytecznym następnym skokiem w tym segmencie.

Co zostaje w tablicy po zakończeniu polecenia

Trasa w Linuksie zapisuje dwie rzeczy, które tu mają znaczenie: następny skok jako adres protokołu i interfejs wyjściowy jako numer indeksu. Atrybuty trasy rtnetlink nazywają to pierwsze pole RTA_GATEWAY, a ono przechowuje bajty. Gdy wpis jest już na miejscu, nie jest do niego przyczepiony żaden TTL i żadne wyszukiwanie w tle go nie odświeża.

Dlatego ip route add 10.44.0.0/16 via vpn-gw.lan może wyglądać, jakby działało. Narzędzie rozwiązuje nazwę w trakcie działania polecenia, zapisuje wynikowy adres i całkowicie zapomina nazwę. Uruchom potem ip route show 10.44.0.0/16 i dostaniesz z powrotem dosłowny adres.

To zachowanie warto znać, zanim obwinisz tunel.

Narzędzia, które rozwiązują nazwę za ciebie, i kiedy

Niektóre routery i zapory faktycznie przyjmują nazwy hostów w polu trasy lub bramy. Ważne jest to, kiedy następuje rozwiązanie. Jeśli urządzenie rozwiązuje nazwę tylko wtedy, gdy stosujesz konfigurację, zapisany wpis jest tak samo statyczny jak wpisany adres, a późniejsza zmiana adresu wymaga kolejnego zastosowania. To, że pole przyjmuje nazwę, nic nie mówi o odświeżaniu.

Zarządzane konfiguracje zwykle dzielą pracę. Rezerwacja DHCP lub statyczna dzierżawa trzyma Pi pod jednym adresem, a rekord DNS po prostu podąża za dzierżawą. Nic nie musi śledzić ruchomego celu, bo cel się nie porusza.

Monitorowany aktualizator to drugi uzasadniony wzorzec i wymaga właściciela.

Przypnij adres albo uruchamiaj aktualizator sam

Dla małej sieci LAN rezerwacja na serwerze DHCP to najtańsze rozwiązanie. Wybierz adres spoza puli dynamicznej, powiąż go z adresem MAC Pi i potwierdź poleceniem ip -4 addr show dev eth0 po kolejnym odnowieniu dzierżawy. Potem skieruj następny skok klientów na ten adres raz. Masz teraz stabilną bramę i rekord, który ją opisuje, i to jest kolejność, w której ta relacja naprawdę działa.

Jeśli Pi naprawdę musi się przenieść, trzymaj naprawę trasy w jednym miejscu zamiast ręcznie edytować każdego klienta. Krótki skrypt, który rozwiązuje, porównuje i zastępuje, wystarczy, by krok był powtarzalny:

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

Ostatnie polecenie to test akceptacyjny, bo wypisuje bramę, której jądro naprawdę użyje. Jeśli wypisany adres nadal jest stary, skrypt działał w złej przestrzeni nazw sieci albo nie miał uprawnień, a strona DNS jest nieistotna.

Sprawdź także drogę powrotną. Pi musi wiedzieć, jak dotrzeć do podsieci klientów, a jego zapora musi przepuszczać ruch tunelu. Trasa domyślna dodana, by zakryć niezgodność, zwykle ukrywa prawdziwą lukę i psuje coś innego tydzień później.