Ali ime gostitelja prehoda Pi samo posodablja statične poti?

Ime DNS za vaš prehod Pi nikoli ne prepiše nameščenega naslednjega skoka. Poglejte, kaj shranjuje jedro in kdo mora posodobiti pot.

Usmerjanje statične poti na ime prehoda je videti, kot da bi morala preživeti spremembo naslova, pa je ne. Ime živi v DNS, medtem ko pot sedi v usmerjevalni tabeli odjemalca kot številčni naslednji skok. Ko se Pi preseli na drug naslov, vsak porabnik, ki je stari skok že namestil, še naprej pošilja promet na isto številko. Noben razreševalnik ni povezan s tabelo posredovanja, zato nič ne prepiše tega vnosa namesto vas.

Odgovor DNS in pot sta različna predmeta

Recimo, da vaš Pi odgovarja na vpn-gw.lan in posreduje 10.44.0.0/16 v tunel. Odjemalci v 192.168.30.0/24 ga dosežejo po statični poti. Ko se je naslov Pi premaknil z 192.168.30.4 na 192.168.30.11, je zapis sledil znotraj svojega TTL, poti pa ne.

Oba pogleda se ne strinjata na način, ki ga je zlahka spregledati, ker oba delujeta verjetno, ko ju vprašate ločeno:

$ 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

Samo prva vrstica odloči, kam gredo paketi. Druga vrstica odgovarja na vprašanje, ki ga jedro ni nikoli postavilo. Zapis z več zapisi A tudi ne postane politika preklopa ob napaki, ker mora biti vsak naslov še vedno uporaben naslednji skok v tem segmentu.

Kaj ostane v tabeli po koncu ukaza

Pot Linuxa zabeleži dve stvari, ki so tu pomembni: naslednji skok kot naslov protokola in izhodni vmesnik kot številko indeksa. atributi poti rtnetlink imenujejo to prvo polje RTA_GATEWAY, in vsebuje bajte. Ko je vnos enkrat na mestu, nanj ni pritrjen noben TTL in nobeno iskanje v ozadju ga ne osveži.

Zato se lahko ip route add 10.44.0.0/16 via vpn-gw.lan zdi, da deluje. Orodje razreši ime, medtem ko ukaz teče, zapiše dobljeni naslov in ime popolnoma pozabi. Zaženite ip route show 10.44.0.0/16 zatem in dobili boste dobesedni naslov nazaj.

To vedenje velja poznati, preden obtožite tunel.

Orodja, ki razrešijo ime namesto vas, in kdaj

Nekateri usmerjevalniki in požarni zidovi res sprejmejo imena gostiteljev v polju poti ali prehoda. Pomembno je, kdaj se razrešitev zgodi. Če naprava ime razreši le med uporabo konfiguracije, je shranjeni vnos prav tako statičen kot vpisan naslov, poznejša sprememba naslova pa zahteva še eno uporabo. To, da polje sprejme ime, vam o osvežitvi ne pove ničesar.

Upravljane nastavitve običajno razdelijo delo. Rezervacija DHCP ali statični najem ohranja Pi na enem naslovu, zapis DNS pa preprosto sledi najemu. Ničemur ni treba slediti premikajočemu se cilju, ker se cilj ne premika.

Nadzorovani posodabljalnik je drug legitimni vzorec in potrebuje lastnika.

Pripnite naslov ali posodabljalnik zaženite sami

Za majhno lokalno omrežje je rezervacija na strežniku DHCP najcenejša rešitev. Izberite naslov zunaj dinamičnega bazena, povežite ga z naslovom MAC Pi in ga potrdite z ip -4 addr show dev eth0 po naslednji obnovitvi najema. Nato usmerite naslednji skok odjemalcev enkrat na ta naslov. Zdaj imate stabilen prehod in zapis, ki ga opisuje, in to je vrstni red, v katerem razmerje v resnici deluje.

Če se mora Pi resnično preseliti, imejte popravilo poti na enem mestu, namesto da bi ročno urejali vsakega odjemalca. Kratka skripta, ki razreši, primerja in zamenja, zadostuje, da je korak ponovljiv:

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

Zadnji ukaz je sprejemni test, ker izpiše prehod, ki ga bo jedro resnično uporabilo. Če je izpisani naslov še vedno star, je skripta tekla v napačnem imenskem prostoru omrežja ali ni imela dovoljenja, stran DNS pa je nepomembna.

Preverite tudi povratno pot. Pi mora vedeti, kako doseči odjemalčevo podomrežje, njegov požarni zid pa mora dovoliti promet tunela. Privzeta pot, dodana, da zakrije neskladje, običajno skrije pravo vrzel in teden dni pozneje pokvari kaj drugega.

Sorodni članki