Aktualizuje názov hostiteľa brány Pi statické trasy sám?
DNS názov vašej brány Pi nikdy neprepíše nainštalovaný ďalší skok. Pozrite sa, čo ukladá jadro a kto musí trasu aktualizovať.
Nasmérovať statickú trasu na názov brány vyzerá, akoby mala prežiť zmenu adresy, a neprežije. Názov žije v DNS, zatiaľ čo trasa sedí v smerovacej tabuľke klienta ako číselný ďalší skok. Keď sa Pi presunie na inú adresu, každý konzument, ktorý už nainštaloval starý skok, posiela prevádzku na to isté číslo ďalej. Žiadny resolver nie je prepojený so smerovacou tabuľkou, takže ten záznam za vás nič neprepíše.
Odpoveď DNS a trasa sú rôzne objekty
Povedzme, že vaša Pi odpovedá na vpn-gw.lan a preposiela 10.44.0.0/16 do tunela. Klienti v 192.168.30.0/24 sa k nej dostanú cez statickú trasu. Keď sa adresa Pi posunula z 192.168.30.4 na 192.168.30.11, záznam ju v rámci svojho TTL nasledoval a trasy nie.
Oba pohľady sa rozchádzajú spôsobom, ktorý sa ľahko prehliadne, pretože oba vyzerajú vierohodne, keď sa na ne pýtate 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
Len prvý riadok rozhoduje, kam pakety pôjdu. Druhý riadok odpovedá na otázku, ktorú jadro nikdy nepoložilo. Záznam s niekoľkými A záznamami sa tiež nestane politikou prepnutia pri výpadku, pretože každá adresa stále musí byť použiteľným ďalším skokom v danom segmente.
Čo v tabuľke zostane po ukončení príkazu
Trasa v Linuxe zaznamenáva dve veci, ktoré tu majú význam: ďalší skok ako adresu protokolu a výstupné rozhranie ako číslo indexu. atribúty trasy rtnetlink nazývajú to prvé pole RTA_GATEWAY a ono drží bajty. Keď je záznam na mieste, nie je k nemu pripojený žiadny TTL a žiadne vyhľadávanie na pozadí ho neobnovuje.
Preto môže ip route add 10.44.0.0/16 via vpn-gw.lan vyzerať, že funguje. Nástroj preloží názov, kým príkaz beží, zapíše výslednú adresu a názov úplne zabudne. Spustite potom ip route show 10.44.0.0/16 a dostanete späť doslovnú adresu.
Toto správanie je dobré poznať, kým začnete viniť tunel.
Nástroje, ktoré za vás preložia názov, a kedy
Niektoré routery a firewally názvy hostiteľov v poli trasy alebo brány naozaj prijímajú. Dôležité je, kedy k prekladu dôjde. Ak zariadenie prekladá názov len pri uplatňovaní konfigurácie, je uložený záznam rovnako statický ako napísaná adresa a neskoršia zmena adresy vyžaduje ďalšie uplatnenie. To, že pole názov prijíma, vám o obnovovaní nehovorí nič.
Spravované prostredia prácu zvyčajne delia. Rezervácia DHCP alebo statický prenájom drží Pi na jednej adrese a záznam DNS prenájom jednoducho nasleduje. Nič nemusí sledovať pohyblivý cieľ, pretože sa cieľ nehýbe.
Monitorovaný aktualizátor je druhý legitímny vzor a potrebuje vlastníka.
Pripnite adresu, alebo aktualizátor spúšťajte sami
Pre malú LAN je rezervácia na serveri DHCP najlacnejšie riešenie. Vyberte adresu mimo dynamického fondu, priviažte ju k MAC adrese Pi a po ďalšom obnovení prenájmu ju potvrďte pomocou ip -4 addr show dev eth0. Potom nasmérujte ďalší skok klientov na túto adresu raz. Teraz máte stabilnú bránu a záznam, ktorý ju popisuje, a to je poradie, v ktorom ten vzťah skutočne funguje.
Ak sa Pi naozaj musí presunúť, držte opravu trasy na jednom mieste, namiesto ručného upravovania každého klienta. Krátky skript, ktorý preloží, porovná a nahradí, stačí na to, aby bol krok opakovateľný:
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ý príkaz je akceptačný test, pretože vypisuje bránu, ktorú jadro skutočne použije. Ak je vypísaná adresa stále stará, skript bežal v nesprávnom sieťovom mennom priestore alebo nemal oprávnenie a strana DNS je irelevantná.
Skontrolujte aj spiatočnú cestu. Pi musí vedieť, ako dosiahnuť klientsku podsiet, a jej firewall musí povoliť prevádzku tunela. Predvolená trasa pridaná, aby nezrovnalosť zakryla, zvyčajne skryje skutočnú medzeru a o týždeň rozbije niečo iné.