Numele de gazdă al gateway-ului Pi actualizează singur rutele statice?

Un nume DNS pentru gateway-ul Pi nu rescrie niciodată un următor salt deja instalat. Vezi ce stochează nucleul și cine trebuie să actualizeze ruta.

Să îndrepți o rută statică spre un nume de gateway pare că ar trebui să supraviețuiască unei schimbări de adresă, și nu o face. Numele trăiește în DNS, în timp ce ruta stă în tabela de rutare a clientului ca următor salt numeric. Când Pi-ul se mută pe altă adresă, fiecare consumator care a instalat deja vechiul salt continuă să trimită trafic către același număr. Niciun resolver nu este conectat la tabela de forwarding, așa că nimic nu rescrie acea intrare pentru tine.

Răspunsul DNS și ruta sunt obiecte diferite

Să spunem că Pi-ul tău răspunde la vpn-gw.lan și redirecționează 10.44.0.0/16 într-un tunel. Clienții din 192.168.30.0/24 ajung la el printr-o rută statică. Când adresa Pi-ului s-a mutat de la 192.168.30.4 la 192.168.30.11, înregistrarea a urmat în interiorul TTL-ului ei, iar rutele nu.

Cele două vederi nu sunt de acord într-un mod ușor de ratat, pentru că ambele par plauzibile când le întrebi separat:

$ 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

Doar prima linie decide unde merg pachetele. A doua linie răspunde la o întrebare pe care nucleul nu a pus-o niciodată. O înregistrare cu mai multe înregistrări A nu devine nici politică de failover, pentru că fiecare adresă trebuie să rămână un următor salt utilizabil în acel segment.

Ce rămâne în tabel după ce comanda se termină

O rută Linux înregistrează două lucruri care contează aici: următorul salt ca adresă de protocol și interfața de ieșire ca număr de index. Atributele de rută rtnetlink numesc acel prim câmp RTA_GATEWAY, iar el conține octeți. Odată ce intrarea este la locul ei, nu i se atașează niciun TTL și nicio căutare din fundal nu o reîmprospătează.

De aceea ip route add 10.44.0.0/16 via vpn-gw.lan poate părea că funcționează. Instrumentul rezolvă numele în timp ce comanda rulează, scrie adresa rezultată și uită complet numele. Rulează ip route show 10.44.0.0/16 după aceea și primești înapoi o adresă literală.

Acest comportament merită cunoscut înainte să dai vina pe tunel.

Instrumente care rezolvă un nume pentru tine, și când

Unele routere și firewall-uri acceptă într-adevăr nume de gazdă într-un câmp de rută sau de gateway. Ce contează este când are loc rezolvarea. Dacă dispozitivul rezolvă numele doar în timp ce aplici configurația, intrarea stocată este la fel de statică precum o adresă tastată, iar o schimbare ulterioară de adresă necesită încă o aplicare. Faptul că câmpul acceptă un nume nu îți spune nimic despre reîmprospătare.

Instalațiile administrate tind să împartă munca. O rezervare DHCP sau un lease static ține Pi-ul pe o singură adresă, iar înregistrarea DNS urmează pur și simplu lease-ul. Nimic nu trebuie să urmărească o țintă mobilă pentru că ținta nu se mișcă.

Un actualizator monitorizat este celălalt tipar legitim și are nevoie de un proprietar.

Fixează adresa sau rulează singur actualizatorul

Pentru o rețea LAN mică, o rezervare pe serverul DHCP este soluția cea mai ieftină. Alege o adresă în afara pool-ului dinamic, leagă-o de adresa MAC a Pi-ului și confirmă-o cu ip -4 addr show dev eth0 după următoarea reînnoire a lease-ului. Apoi îndreaptă o singură dată următorul salt al clienților spre acea adresă. Acum ai un gateway stabil și o înregistrare care îl descrie, iar aceasta este ordinea în care relația funcționează de fapt.

Dacă Pi-ul chiar trebuie să se mute, ține repararea rutei într-un singur loc în loc să editezi fiecare client manual. Un script scurt care rezolvă, compară și înlocuiește este suficient pentru a face pasul repetabil:

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

Ultima comandă este testul de acceptare, pentru că tipărește gateway-ul pe care nucleul îl va folosi efectiv. Dacă adresa tipărită este încă cea veche, scriptul a rulat în spațiul de nume de rețea greșit sau nu avea permisiunea, iar partea DNS este irelevantă.

Verifică și calea de întoarcere. Pi-ul trebuie să știe cum să ajungă la subrețeaua clienților, iar firewall-ul lui trebuie să permită traficul tunelului. O rută implicită adăugată pentru a acoperi nepotrivirea ascunde de obicei golul real și strică altceva o săptămână mai târziu.

Articole similare