Staatilise marsruudi suunamine lüüsi nimele tundub nii, nagu peaks see aadressimuutuse üle elama, ja ei ela. Nimi elab DNS-is, samal ajal kui marsruut istub kliendi marsruutimistabelis numbrilise järgmise hüppena. Kui Pi liigub teisele aadressile, jätkab iga tarbija, kes on vana hüppe juba paigaldanud, liikluse saatmist samale numbrile. Ükski lahendaja ei ole edastustabeliga ühendatud, seega ei kirjuta miski seda kirjet sinu eest ümber.

DNS-vastus ja marsruut on erinevad objektid

Oletame, et sinu Pi vastab aadressile vpn-gw.lan ja edastab 10.44.0.0/16 tunnelisse. Kliendid võrgus 192.168.30.0/24 jõuavad selleni staatilise marsruudi kaudu. Kui Pi aadress liikus 192.168.30.4-lt 192.168.30.11-le, järgnes kirje oma TTL-i piires ja marsruudid mitte.

Kaks vaadet lahknevad viisil, mida on lihtne märkamata jätta, sest mõlemad tunduvad usutavad, kui neid eraldi küsida:

$ 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

Ainult esimene rida otsustab, kuhu paketid lähevad. Teine rida vastab küsimusele, mida kernel kunagi ei küsinud. Kirje, millel on mitu A-kirjet, ei muutu ka ümberlülituse poliitikaks, sest iga aadress peab selles segmendis ikka olema kasutatav järgmine hüpe.

Mis tabelisse jääb pärast käsu lõppemist

Linuxi marsruut salvestab kaks asja, mis siin loevad: järgmise hüppe protokolliaadressina ja väljundliidese indeksinumbri. rtnetlinki marsruudi atribuudid nimetavad selle esimese välja RTA_GATEWAY, ja see hoiab baite. Kui kirje on paigas, ei ole sellele lisatud ühtegi TTL-i ja ükski taustapäring ei värskenda seda.

Seetõttu võib ip route add 10.44.0.0/16 via vpn-gw.lan näida töötavat. Tööriist lahendab nime käsu töötamise ajal, kirjutab saadud aadressi ja unustab nime täielikult. Käivita pärast seda ip route show 10.44.0.0/16 ja saad tagasi sõnasõnalise aadressi.

Seda käitumist tasub teada enne, kui tunneli süüdi teed.

Tööriistad, mis lahendavad nime sinu eest, ja millal

Mõned ruuterid ja tulemüürid võtavad tõesti hostinimesid vastu marsruudi- või lüüsiväljas. Tähtis on see, millal lahendamine toimub. Kui seade lahendab nime ainult siis, kui konfiguratsiooni rakendad, on salvestatud kirje sama staatiline kui trükitud aadress, ja hilisem aadressimuutus nõuab veel üht rakendamist. See, et väli nime vastu võtab, ei ütle sulle värskendamise kohta midagi.

Hallatud seadistused jagavad töö tavaliselt ära. DHCP-reserveering või staatiline rent hoiab Pi ühel aadressil, ja DNS-kirje lihtsalt järgib renti. Miski ei pea jälgima liikuvat sihtmärki, sest sihtmärk ei liigu.

Jälgitud uuendaja on teine legitiimne muster, ja see vajab omanikku.

Kinnita aadress või käivita uuendaja ise

Väikese kohtvõrgu jaoks on DHCP-serveri reserveering kõige odavam lahendus. Vali aadress väljaspool dünaamilist vahemikku, seo see Pi MAC-aadressiga ja kinnita ip -4 addr show dev eth0-ga pärast järgmist rendi uuendamist. Seejärel suuna klientide järgmine hüpe üks kord sellele aadressile. Nüüd on sul stabiilne lüüs ja kirje, mis seda kirjeldab, ja see on järjekord, milles suhe tegelikult toimib.

Kui Pi peab tõesti liikuma, hoia marsruudi parandus ühes kohas, selle asemel et iga klienti käsitsi muuta. Lühike skript, mis lahendab, võrdleb ja asendab, on piisav, et sammu korratavaks teha:

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

Viimane käsk on vastuvõtutest, sest see prindib lüüsi, mida kernel tegelikult kasutab. Kui prinditud aadress on endiselt vana, jooksis skript vales võrgu nimeruumis või puudus luba, ja DNS-i pool on ebaoluline.

Kontrolli ka tagasiteed. Pi peab teadma, kuidas kliendi alamvõrku jõuda, ja selle tulemüür peab tunneli liiklust lubama. Vahekokkusobimatuse katmiseks lisatud vaikemarsruut peidab tavaliselt tegeliku lünga ja lõhub nädala pärast midagi muud.

Seotud artiklid