A e përditëson vetë emri i hostit të portës Pi rrugët statike?

Një emër DNS për portën tuaj Pi nuk rishkruan kurrë një hap tjetër të instaluar. Shihni çfarë ruan kerneli dhe kush duhet ta përditësojë rrugën.

Drejtimi i një rruge statike nga një emër porte duket sikur duhet t'i mbijetojë një ndryshimi adrese, dhe nuk i mbijeton. Emri jeton në DNS, ndërsa rruga qëndron në tabelën e rrugëzimit të klientit si një hap tjetër numerik. Kur Pi kalon në një adresë tjetër, çdo konsumator që e ka instaluar tashmë hapin e vjetër vazhdon të dërgojë trafik në të njëjtin numër. Asnjë zgjidhës nuk është i lidhur me tabelën e përcjelljes, kështu që asgjë nuk e rishkruan atë zë në vendin tuaj.

Përgjigja DNS dhe rruga janë objekte të ndryshme

Le të themi se Pi juaj përgjigjet në vpn-gw.lan dhe përcjell 10.44.0.0/16 në një tunel. Klientët në 192.168.30.0/24 e arrijnë përmes një rruge statike. Kur adresa e Pi u zhvendos nga 192.168.30.4 në 192.168.30.11, regjistri e ndoqi brenda TTL-së së tij dhe rrugët nuk e ndoqën.

Dy pamjet nuk pajtohen në një mënyrë që humbet lehtë, sepse të dyja duken të besueshme kur i pyet veçmas:

$ 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

Vetëm rreshti i parë vendos ku shkojnë paketat. Rreshti i dytë i përgjigjet një pyetjeje që kerneli nuk e bëri kurrë. Një regjistrim me disa regjistrime A gjithashtu nuk bëhet politikë e kalimit në rast dështimi, sepse çdo adresë duhet ende të jetë një hap tjetër i përdorshëm në atë segment.

Çfarë mbetet në tabelë pasi komanda të dalë

Një rrugë Linux regjistron dy gjëra që kanë rëndësi këtu: hapin tjetër si adresë protokolli, dhe ndërfaqen dalëse si numër indeksi. atributet e rrugës rtnetlink e quajnë atë fushë të parë RTA_GATEWAY, dhe ajo mban bajt. Pasi zëri të jetë në vend, asnjë TTL nuk i është bashkangjitur dhe asnjë kërkim në sfond nuk e rifreskon atë.

Kjo është arsyeja pse ip route add 10.44.0.0/16 via vpn-gw.lan mund të duket se funksionon. Mjeti e zgjidh emrin ndërsa komanda ekzekutohet, shkruan adresën që rezulton dhe e harron plotësisht emrin. Ekzekutoni ip route show 10.44.0.0/16 më pas dhe merrni mbrapsht një adresë fjalë për fjalë.

Ajo sjellje ia vlen të njihet përpara se të fajësoni tunelin.

Mjete që zgjidhin një emër për ju, dhe kur

Disa ruter dhe mure zjarri vërtet pranojnë emra hosti në një fushë rruge ose porte. Ajo që ka rëndësi është kur ndodh zgjidhja. Nëse pajisja e zgjidh emrin vetëm ndërsa ju aplikoni konfigurimin, zëri i ruajtur është po aq statik sa një adresë e shtypur, dhe një ndryshim i mëvonshëm adrese kërkon një aplikim tjetër. Fakti që fusha pranon një emër nuk ju thotë asgjë për rifreskimin.

Konfigurimet e menaxhuara priren ta ndajnë punën. Një rezervim DHCP ose një qira statike e mban Pi në një adresë, dhe regjistri DNS thjesht ndjek qiranë. Asgjë nuk duhet të ndjekë një objektiv në lëvizje sepse objekti nuk lëviz.

Një përditësues i monitoruar është modeli tjetër legjitim, dhe kërkon një pronar.

Fiksoni adresën ose ekzekutoni vetë përditësuesin

Për një LAN të vogël, një rezervim në serverin DHCP është zgjidhja më e lirë. Zgjidhni një adresë jashtë grupit dinamik, lidheni me adresën MAC të Pi dhe konfirmojeni me ip -4 addr show dev eth0 pas rinovimit të ardhshëm të qirasë. Pastaj drejtojeni një herë hapin tjetër të klientëve në atë adresë. Tani keni një portë të qëndrueshme dhe një regjistrim që e përshkruan, dhe ky është rendi në të cilin lidhja funksionon vërtet.

Nëse Pi vërtet duhet të zhvendoset, mbajeni riparimin e rrugës në një vend të vetëm në vend që të modifikoni manualisht çdo klient. Një skript i shkurtër që zgjidh, krahason dhe zëvendëson mjafton për ta bërë hapin të përsëritshëm:

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

Komanda e fundit është testi i pranimit, sepse shtyp portën që kerneli do të përdorë vërtet. Nëse adresa e shtypur është ende e vjetra, skripti është ekzekutuar në hapësirën e gabuar të emrave të rrjetit ose nuk kishte leje, dhe ana e DNS-së është e parëndësishme.

Kontrolloni edhe rrugën e kthimit. Pi duhet të dijë si ta arrijë nënrrjetin e klientëve, dhe muri i tij i zjarrit duhet të lejojë trafikun e tunelit. Një rrugë e paracaktuar e shtuar për të mbuluar mospërputhjen zakonisht fsheh boshllëkun e vërtetë dhe prish diçka tjetër një javë më vonë.

Artikuj të ngjashëm