Uppfærir hýsilnafn Pi-gáttarins kyrrstæðar leiðir sjálft?

Að beina kyrrstæðri leið að nafni gáttar virðist eiga að lifa af vistfangsbreytingu, og það gerir það ekki. Nafnið býr í DNS, en leiðin situr í leiðarvísitöflu biðlarans sem tölulegt næsta hopp. Þegar Pi flyst á annað vistfang heldur hver neytandi sem þegar hefur sett upp gamla hoppið áfram að senda umferð á sama númer. Enginn leysir er tengdur við áframsendingartöfluna, svo ekkert endurskrifar þá færslu fyrir þig.

DNS-svarið og leiðin eru ólíkir hlutir

Segjum að Pi þín svari á vpn-gw.lan og áframsendi 10.44.0.0/16 inn í göng. Biðlarar á 192.168.30.0/24 ná til hennar um kyrrstæða leið. Þegar vistfang Pi flutti frá 192.168.30.4 yfir í 192.168.30.11 fylgdi færslan innan TTL síns og leiðirnar ekki.

Þessar tvær sýnir stangast á á þann hátt sem er auðvelt að missa af, því báðar virðast trúverðugar þegar maður spyr um þær sitt í hvoru lagi:

$ 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

Aðeins fyrsta línan ræður því hvert pakkarnir fara. Önnur línan svarar spurningu sem kjarninn lagði aldrei. Færsla með nokkrum A-færslum verður heldur ekki að bilanatillögu, því hvert vistfang verður áfram að vera nothæft næsta hopp á þeim hluta.

Hvað verður eftir í töflunni þegar skipunin hættir

Linux-leið skráir tvennt sem skiptir máli hér: næsta hopp sem prótókólvistfang, og útgangsviðmótið sem vísitölu. rtnetlink-leiðareiginleikarnir nefna það fyrsta svið RTA_GATEWAY, og það geymir bæti. Þegar færslan er komin á sinn stað er engu TTL fest við hana og ekkert bakgrunnsleit endurnýjar hana.

Þess vegna getur ip route add 10.44.0.0/16 via vpn-gw.lan virst virka. Tólið leysir nafnið á meðan skipunin keyrir, skrifar vistfangið sem kemur út og gleymir nafninu algjörlega. Keyrðu ip route show 10.44.0.0/16 eftir á og þú færð bókstaflegt vistfang til baka.

Þessa hegðun er vert að þekkja áður en þú kennir göngunum um.

Tól sem leysa nafn fyrir þig, og hvenær

Sumir beinar og eldveggir taka raunar við hýsilnöfnum í leiðar- eða gáttarsviði. Það sem skiptir máli er hvenær leysingin á sér stað. Ef tækið leysir nafnið aðeins meðan þú beitir stillingunni er geymda færslan jafn kyrrstæð og innslegið vistfang, og síðari vistfangsbreyting krefst annarrar beitingar. Að sviðið taki við nafni segir þér ekkert um endurnýjun.

Stýrðar uppsetningar skipta vinnunni yfirleitt. DHCP-fyrirvari eða kyrrstæð leiga heldur Pi á einu vistfangi, og DNS-færslan fylgir einfaldlega leigunni. Ekkert þarf að elta hreyfanlegt skotmark því skotmarkið hreyfist ekki.

Eftirlitsuppfærir er hitt lögmæta mynstrið, og það þarf eiganda.

Festið vistfangið eða keyrið uppfærirann sjálf

Fyrir lítið staðarnet er fyrirvari á DHCP-þjóninum ódýrasta lausnin. Veldu vistfang utan hreyfanlega hópsins, bindu það við MAC-vistfang Pi og staðfestu það með ip -4 addr show dev eth0 eftir næstu leiguendurnýjun. Síðan beindu næsta hoppi biðlaranna að því vistfangi einu sinni. Nú hefur þú stöðuga gátt og færslu sem lýsir henni, og það er sú röð sem sambandið virkar í raun eftir.

Ef Pi verður raunverulega að flytjast skaltu halda leiðarviðgerðinni á einum stað í stað þess að breyta hverjum biðlara fyrir sig. Stutt skrift sem leysir, ber saman og skiptir út er nóg til að gera skrefið endurtakanlegt:

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

Síðasta skipunin er samþykkispref, því hún prentar gáttina sem kjarninn mun raunverulega nota. Ef prentaða vistfangið er enn gamalt keyrði skriftin í röngu netnafnrými eða hafði ekki heimild, og DNS-hliðin er óviðkomandi.

Athugaðu líka endurkomuleiðina. Pi verður að vita hvernig á að ná í biðlarahlutanetið, og eldveggur hennar verður að leyfa umferð gagnanna. Sjálfgefin leið sem bætt er við til að hylja misræmið felur venjulega raunverulegu eyðuna og brýtur eitthvað annað viku síðar.