Ar Pi tinklų sietuvo mazgo vardas pats atnaujina statinius maršrutus?

Statinio maršruto nukreipimas į sietuvo vardą atrodo taip, tarsi jis turėtų išgyventi adreso pasikeitimą, bet neišgyvena. Vardas gyvena DNS, o maršrutas sėdi kliento maršrutizavimo lentelėje kaip skaitinis kitas šuolis. Kai Pi persikelia į kitą adresą, kiekvienas vartotojas, kuris jau įdiegė seną šuolį, toliau siunčia srautą tuo pačiu numeriu. Joks resolveris nėra prijungtas prie persiuntimo lentelės, todėl niekas to įrašo už jus neperrašo.

DNS atsakymas ir maršrutas yra skirtingi objektai

Tarkime, jūsų Pi atsako į vpn-gw.lan ir persiunčia 10.44.0.0/16 į tunelį. Klientai 192.168.30.0/24 tinkle pasiekia jį statiniu maršrutu. Kai Pi adresas pasikeitė iš 192.168.30.4 į 192.168.30.11, įrašas sekė per savo TTL, o maršrutai ne.

Abu vaizdai nesutaria taip, kad tai lengva praleisti, nes abu atrodo įtikinamai, kai klausiate jų atskirai:

$ 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

Tik pirmoji eilutė nusprendžia, kur paketai keliauja. Antroji eilutė atsako į klausimą, kurio branduolys niekada neužduoda. Įrašas su keliais A įrašais taip pat netampa perjungimo gedimo metu politika, nes kiekvienas adresas vis tiek turi būti veikiantis kitas šuolis tame segmente.

Kas lieka lentelėje po to, kai komanda baigia darbą

Linux maršrutas įrašo du dalykus, kurie čia svarbūs: kitą šuolį kaip protokolo adresą ir išėjimo sąsają kaip indekso numerį. rtnetlink maršruto atributai vadina tą pirmąjį lauką RTA_GATEWAY, ir jame laikomi baitai. Kai įrašas yra savo vietoje, prie jo nepridėtas joks TTL ir joks foninis ieškojimas jo neatnaujina.

Štai kodėl ip route add 10.44.0.0/16 via vpn-gw.lan gali atrodyti veikiantis. Įrankis išsprendžia vardą, kol komanda vykdoma, įrašo gautą adresą ir visiškai pamiršta vardą. Paleiskite ip route show 10.44.0.0/16 po to ir gausite pažodinį adresą.

Šią elgseną verta žinoti prieš kaltinant tunelį.

Įrankiai, kurie išsprendžia vardą už jus, ir kada

Kai kurie maršrutizatoriai ir užkardos tikrai priima mazgų vardus maršruto ar sietuvo lauke. Svarbu tai, kada įvyksta sprendimas. Jei įrenginys sprendžia vardą tik tada, kai taikote konfigūraciją, saugomas įrašas yra toks pat statinis kaip įrašytas adresas, o vėlesniam adreso pakeitimui reikia dar vieno taikymo. Tai, kad laukas priima vardą, nieko nesako apie atnaujinimą.

Valdomos sąrankos paprastai pasidalija darbą. DHCP rezervacija arba statinė nuoma laiko Pi viename adrese, o DNS įrašas tiesiog seka nuomą. Niekas neturi sekti judančio taikinio, nes taikinys nejuda.

Stebimas atnaujintuvas yra kitas teisėtas modelis, ir jam reikia savininko.

Prisekite adresą arba paleiskite atnaujintuvą patys

Mažam LAN tinklui rezervacija DHCP serveryje yra pigiausias sprendimas. Pasirinkite adresą už dinaminio baseino ribų, susiekite jį su Pi MAC adresu ir patvirtinkite su ip -4 addr show dev eth0 po kito nuomos atnaujinimo. Tada vieną kartą nukreipkite klientų kitą šuolį į tą adresą. Dabar turite stabilų sietuvą ir įrašą, kuris jį aprašo, ir tai yra tvarka, kuria šis ryšys iš tikrųjų veikia.

Jei Pi tikrai turi persikelti, laikykite maršruto taisymą vienoje vietoje, o ne redaguokite kiekvieną klientą rankiniu būdu. Trumpas scenarijus, kuris išsprendžia, palygina ir pakeičia, yra pakankamas, kad žingsnis būtų kartojamas:

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

Paskutinė komanda yra priėmimo testas, nes ji atspausdina sietuvą, kurį branduolys tikrai naudos. Jei atspausdintas adresas vis dar senas, scenarijus veikė neteisingoje tinklo vardų erdvėje arba neturėjo leidimo, o DNS pusė yra nesvarbi.

Patikrinkite ir grįžimo kelią. Pi turi žinoti, kaip pasiekti klientų potinklį, o jo užkarda turi leisti tunelio srautą. Numatytasis maršrutas, pridėtas neatitikimui uždengti, paprastai paslepia tikrąją spragą ir po savaitės sugadina ką nors kita.