Awtomatiko bang ina-update ng hostname ng Pi gateway ang mga static na ruta?

Ang pagturo ng static na ruta sa isang pangalan ng gateway ay parang dapat itong mabuhay sa pagbabago ng address, at hindi ito nagagawa. Ang pangalan ay naninirahan sa DNS, samantalang ang ruta ay nakaupo sa routing table ng kliyente bilang isang numerikong susunod na hop. Kapag lumipat ang Pi sa ibang address, bawat consumer na nag-install na ng lumang hop ay patuloy na nagpapadala ng trapiko sa parehong numero. Walang resolver na nakakabit sa forwarding table, kaya walang nagsusulat muli ng entry na iyon para sa iyo.

Ang sagot ng DNS at ang ruta ay magkaibang bagay

Sabihin nating sumasagot ang Pi mo sa vpn-gw.lan at ipinapasa ang 10.44.0.0/16 sa isang tunnel. Naabot ito ng mga kliyente sa 192.168.30.0/24 sa pamamagitan ng static na ruta. Nang lumipat ang address ng Pi mula 192.168.30.4 patungong 192.168.30.11, sumunod ang record sa loob ng TTL nito at hindi sumunod ang mga ruta.

Hindi nagkakasundo ang dalawang pananaw sa paraang madaling makaligtaan, dahil pareho silang mukhang makatwiran kapag tanungin mo sila nang hiwalay:

$ 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

Tanging ang unang linya ang nagpapasya kung saan pupunta ang mga packet. Ang ikalawang linya ay sumasagot sa tanong na hindi kailanman itinanong ng kernel. Ang isang record na may maraming A record ay hindi rin nagiging patakaran ng failover, dahil kailangan pa ring maging gumaganang susunod na hop ang bawat address sa segment na iyon.

Ano ang natitira sa table pagkatapos lumabas ng command

Ang ruta ng Linux ay nagtatala ng dalawang bagay na mahalaga dito: ang susunod na hop bilang address ng protocol, at ang outgoing interface bilang index number. Ang mga attribute ng ruta ng rtnetlink ay tinatawag ang unang field na iyon na RTA_GATEWAY, at mayroon itong bytes. Kapag nakalagay na ang entry, walang TTL na nakakabit dito at walang background lookup na nagre-refresh nito.

Iyan ang dahilan kung bakit maaaring mukhang gumagana ang ip route add 10.44.0.0/16 via vpn-gw.lan. Nireresolba ng tool ang pangalan habang tumatakbo ang command, isinusulat ang resultang address, at tuluyang nakakalimutan ang pangalan. Patakbuhin ang ip route show 10.44.0.0/16 pagkatapos at makakakuha ka ng literal na address pabalik.

Nagkakahalaga ng pag-alam sa gawi na iyon bago mo sisihin ang tunnel.

Mga tool na nagreresolba ng pangalan para sa iyo, at kailan

May mga router at firewall na talagang tumatanggap ng hostname sa field ng ruta o gateway. Ang mahalaga ay kung kailan nangyayari ang resolusyon. Kung nireresolba ng device ang pangalan habang inilalapat mo lang ang configuration, ang nakaimbak na entry ay kasing-static ng isang na-type na address, at ang pagbabago ng address sa hinaharap ay nangangailangan ng isa pang paglalapat. Ang pagtanggap ng field ng isang pangalan ay walang sinasabi sa iyo tungkol sa pag-refresh.

Ang mga pinamamahalaang setup ay may posibilidad na hatiin ang trabaho. Ang isang DHCP reservation o static na lease ay nagpapanatili sa Pi sa isang address, at ang DNS record ay sumusunod lamang sa lease. Walang kailangang sumubaybay sa gumagalaw na target dahil hindi gumagalaw ang target.

Ang isang sinusubaybayang updater ay ang isa pang lehitimong pattern, at kailangan nito ng may-ari.

Ipin mo ang address o patakbuhin mo mismo ang updater

Para sa maliit na LAN, ang reservation sa DHCP server ang pinakamurang solusyon. Pumili ng address sa labas ng dynamic pool, itali ito sa MAC address ng Pi, at kumpirmahin ito gamit ang ip -4 addr show dev eth0 pagkatapos ng susunod na pag-renew ng lease. Pagkatapos ituro nang isang beses ang susunod na hop ng mga kliyente sa address na iyon. Mayroon ka nang matatag na gateway at record na naglalarawan dito, at iyon ang pagkakasunod-sunod kung saan talagang gumagana ang relasyon.

Kung talagang kailangang lumipat ang Pi, itago ang pag-aayos ng ruta sa isang lugar sa halip na i-edit ang bawat kliyente nang manu-mano. Sapat na ang maikling script na nagreresolba, naghahambing at nagpapalit upang gawing mauulit ang hakbang:

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

Ang huling command ay ang acceptance test, dahil ipinapakita nito ang gateway na talagang gagamitin ng kernel. Kung ang nakalimbag na address ay luma pa rin, tumakbo ang script sa maling network namespace o walang pahintulot, at ang panig ng DNS ay walang kaugnayan.

Suriin din ang daan pabalik. Kailangang malaman ng Pi kung paano maabot ang subnet ng mga kliyente, at dapat pahintulutan ng firewall nito ang trapiko ng tunnel. Ang isang default na ruta na idinagdag upang tabunan ang pagkakaiba ay karaniwang nagtatago ng tunay na puwang at sinira ang ibang bagay makalipas ang isang linggo.