Werk 'n gasheernaam vir die Pi-gateway statiese roetes vanself by?

'n DNS-naam vir jou Pi-gateway herskryf nooit 'n geïnstalleerde volgende sprong nie. Kyk wat die kernel stoor en wie die roete moet opdateer.

Om 'n statiese roete na 'n gateway-naam te wys, voel of dit 'n adresverandering behoort te oorleef, en dit doen nie. Die naam woon in DNS, terwyl die roete in die kliënt se roetevertaling as 'n numeriese volgende sprong sit. Wanneer die Pi na 'n ander adres skuif, hou elke verbruiker wat die ou sprong reeds geïnstalleer het, verkeer na dieselfde nommer stuur. Geen oplosser is aan die aanstuurtafel gekoppel nie, so niks herskryf daardie inskrywing vir jou nie.

Die DNS-antwoord en die roete is verskillende objekte

Sê jou Pi antwoord op vpn-gw.lan en stuur 10.44.0.0/16 oor 'n tonnel aan. Kliënte op 192.168.30.0/24 bereik dit deur 'n statiese roete. Toe die Pi se adres van 192.168.30.4 na 192.168.30.11 verskuif het, het die rekord binne sy TTL gevolg en die roetes nie.

Die twee sienings stem nie ooreen nie, op 'n manier wat maklik is om mis te kyk, want albei lyk geloofwaardig wanneer jy hulle afsonderlik bevraagteken:

$ 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

Net die eerste reël besluit waar pakkette heen gaan. Die tweede reël antwoord 'n vraag wat die kernel nooit gevra het nie. 'n Rekord met verskeie A-rekords word ook nie 'n oorskakelbeleid nie, want elke adres moet steeds 'n werkbare volgende sprong op daardie segment wees.

Wat in die tabel oorleef nadat die opdrag afgesluit het

'n Linux-roete teken twee dinge aan wat hier saak maak: die volgende sprong as 'n protokoladres, en die uitgangsintervlak as 'n indeksnommer. Die rtnetlink-roete-attribute noem daardie eerste veld RTA_GATEWAY, en dit hou grepe. Sodra die inskrywing in plek is, is geen TTL daaraan gekoppel nie en geen agtergrondsoektog verfris dit nie.

Dit is waarom ip route add 10.44.0.0/16 via vpn-gw.lan kan lyk of dit werk. Die hulpmiddel los die naam op terwyl die opdrag loop, skryf die resulterende adres, en vergeet die naam heeltemal. Voer ip route show 10.44.0.0/16 daarna uit en jy kry 'n letterlike adres terug.

Daardie gedrag is die moeite werd om te ken voordat jy die tonnel blameer.

Gereedskap wat 'n naam vir jou oplos, en wanneer

Sommige routers en firewalls aanvaar wel gasheername in 'n roete- of gateway-veld. Wat saak maak, is wanneer die oplossing gebeur. As die toestel die naam net oplos terwyl jy die konfigurasie toepas, is die gestoorde inskrywing net so staties soos 'n getikte adres, en 'n latere adresverandering vereis nog 'n toepassing. Die veld wat 'n naam aanvaar, sê niks vir jou oor verversing nie.

Bestuurde omgewings verdeel gewoonlik die werk. 'n DHCP-bespreking of statiese huur hou die Pi op een adres, en die DNS-rekord volg bloot die huur. Niks hoef 'n bewegende teiken te volg nie, want die teiken beweeg nie.

'n Opdatering wat dopgehou word, is die ander wettige patroon, en dit het 'n eienaar nodig.

Spyker die adres vas of laat die opdatering self loop

Vir 'n klein LAN is 'n bespreking op die DHCP-bediener die goedkoopste oplossing. Kies 'n adres buite die dinamiese poel, bind dit aan die Pi se MAC-adres, en bevestig dit met ip -4 addr show dev eth0 ná die volgende huurhernuwing. Dan wys die kliënte se volgende sprong een keer na daardie adres. Jy het nou 'n stabiele gateway en 'n rekord wat dit beskryf, wat die orde is waarin die verhouding werklik werk.

As die Pi werklik moet skuif, hou die roeteherstel op een plek in plaas daarvan om elke kliënt met die hand te redigeer. 'n Kort skrip wat oplos, vergelyk en vervang is genoeg om die stap herhaalbaar te maak:

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

Die laaste opdrag is die aanvaardingstoets, want dit druk die gateway wat die kernel werklik gaan gebruik. As die gedrukte adres nog die ou een is, het die skrip in die verkeerde netwerknaamruimte geloop of het toestemming kortgekom, en die DNS-kant is irrelevant.

Kontroleer ook die terugpad. Die Pi moet weet hoe om die kliënt-subnet te bereik, en sy firewall moet die tonnelverkeer toelaat. 'n Standaardroete wat bygevoeg word om die wanverhouding toe te smeer, verberg gewoonlik die werklike leemte en breek 'n week later iets anders.

Verwante artikels