Aktualizuje název hostitele brány Pi statické trasy sám?

DNS název vaší brány Pi nikdy nepřepíše nainstalovaný další skok. Podívejte se, co jádro ukládá a kdo musí trasu aktualizovat.

Nasměrovat statickou trasu na název brány vypadá, jako by mělo přežít změnu adresy, a nepřežije. Název žije v DNS, zatímco trasa sedí v směrovací tabulce klienta jako číselný další skok. Když se Pi přesune na jinou adresu, každý konzument, který už starý skok nainstaloval, posílá provoz na stejné číslo dál. Žádný resolver není propojen se směrovací tabulkou, takže ten záznam za vás nic nepřepíše.

Odpověď DNS a trasa jsou různé objekty

Řekněme, že vaše Pi odpovídá na vpn-gw.lan a přeposílá 10.44.0.0/16 do tunelu. Klienti v 192.168.30.0/24 se k němu dostanou přes statickou trasu. Když se adresa Pi přesunula z 192.168.30.4 na 192.168.30.11, záznam ji v rámci svého TTL následoval a trasy ne.

Oba pohledy se rozcházejí způsobem, který se snadno přehlédne, protože oba vypadají věrohodně, když se na ně ptáte zvlášť:

$ 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

Jen první řádek rozhoduje, kam pakety půjdou. Druhý řádek odpovídá na otázku, kterou jádro nikdy nepoložilo. Záznam s několika A záznamy se také nestane politikou přepnutí při výpadku, protože každá adresa stále musí být použitelným dalším skokem v daném segmentu.

Co v tabulce zůstane po ukončení příkazu

Trasa v Linuxu zaznamenává dvě věci, které tu mají význam: další skok jako adresu protokolu a výstupní rozhraní jako číslo indexu. atributy trasy rtnetlink nazývají to první pole RTA_GATEWAY a ono drží bajty. Jakmile je záznam na místě, není k němu připojen žádný TTL a žádné vyhledávání na pozadí ho neobnovuje.

Proto může ip route add 10.44.0.0/16 via vpn-gw.lan vypadat, že funguje. Nástroj název přeloží, dokud příkaz běží, zapíše výslednou adresu a název úplně zapomene. Spusťte potom ip route show 10.44.0.0/16 a dostanete zpět doslovnou adresu.

Tohle chování je dobré znát, než začnete vinit tunel.

Nástroje, které za vás název přeloží, a kdy

Některé routery a firewally názvy hostitelů v poli trasy nebo brány opravdu přijímají. Důležité je, kdy k překladu dojde. Pokud zařízení název překládá jen při uplatňování konfigurace, je uložený záznam stejně statický jako napsaná adresa a pozdější změna adresy vyžaduje další uplatnění. To, že pole název přijímá, vám o obnovování neříká nic.

Spravovaná prostředí práci obvykle rozdělují. Rezervace DHCP nebo statický pronájem drží Pi na jedné adrese a záznam DNS pronájem prostě následuje. Nic nemusí sledovat pohyblivý cíl, protože se cíl nehýbe.

Monitorovaný aktualizátor je druhý legitimní vzor a potřebuje vlastníka.

Připněte adresu, nebo aktualizátor spouštějte sami

Pro malou LAN je rezervace na serveru DHCP nejlevnější řešení. Vyberte adresu mimo dynamický fond, přivažte ji k MAC adrese Pi a po dalším obnovení pronájmu ji potvrďte pomocí ip -4 addr show dev eth0. Potom nasměrujte další skok klientů na tuto adresu jednou. Teď máte stabilní bránu a záznam, který ji popisuje, což je pořadí, ve kterém ten vztah skutečně funguje.

Pokud se Pi opravdu musí přesunout, držte opravu trasy na jednom místě, místo ručního upravování každého klienta. Krátký skript, který přeloží, porovná a nahradí, stačí k tomu, aby byl krok opakovatelný:

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

Poslední příkaz je akceptační test, protože vypisuje bránu, kterou jádro skutečně použije. Pokud je vypsaná adresa stále stará, skript běžel ve špatném síťovém jmenném prostoru nebo neměl oprávnění a strana DNS je irelevantní.

Zkontrolujte i zpáteční cestu. Pi musí vědět, jak dosáhnout klientské podsítě, a její firewall musí povolit provoz tunelu. Výchozí trasa přidaná, aby nesoulad zakryla, obvykle skryje skutečnou mezeru a za týden rozbije něco jiného.

Související články