In statyske rûte nei in gateway-namme wize fielt as soe it in adreswiziging oerlibje moatte, en dat docht it net. De namme wennet yn DNS, wylst de rûte as in numerike folgjende hop yn 'e routingtabel fan 'e klient sit. As de Pi nei in oar adres ferhuzet, bliuwt elke brûker dy't de âlde hop al ynstallearre hat, ferkear nei itselde nûmer stjoere. Gjin resolver is oan 'e trochstjoertabel fêstmakke, dus neat skriuwt dy ynskriuwing foar dy oer.

It DNS-antwurd en de rûte binne ferskillende objekten

Stel dat dyn Pi antwurdet op vpn-gw.lan en 10.44.0.0/16 nei in tunnel trochstjoert. Klanten op 192.168.30.0/24 berikke it fia in statyske rûte. Doe't it adres fan 'e Pi fan 192.168.30.4 nei 192.168.30.11 ferhuze, folge it record binnen syn TTL en de rûtes net.

De beide bylden binne it net iens op in manier dy't maklik te missen is, want beide lykje leauwensweardich as men se apart befreget:

$ 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

Allinnich de earste rigel beslút wêr't pakketten hinne gean. De twadde rigel antwurdet in fraach dy't de kernel nea steld hat. In record mei ferskate A-records wurdt ek gjin failover-belied, want elk adres moat noch altyd in wurkjende folgjende hop op dat segmint wêze.

Wat yn 'e tabel oerbliuwt nei't it kommando einiget

In Linux-rûte skriuwt twa dingen op dy't hjir ta saak dogge: de folgjende hop as protokoladres, en de útgongsinterface as yndeksnûmer. De rtnetlink-rûteattributen neame dat earste fjild RTA_GATEWAY, en it hâldt bytes. As de ynskriuwing ienris op syn plak is, hinget der gjin TTL oan en gjin eftergrûnsoersetting fernijt it.

Dêrom kin ip route add 10.44.0.0/16 via vpn-gw.lan lykje as wurket it. It ark lost de namme op wylst it kommando rint, skriuwt it resultearjende adres, en ferjit de namme folslein. Rin ip route show 10.44.0.0/16 dêrnei en do krijst in letterlik adres werom.

Dat gedrach is it witten wurdich foardatst de tunnel de skuld jout.

Ark dat in namme foar dy oplost, en wannear

Guon routers en firewalls akseptearje wol hostnammen yn in rûte- of gatewayfjild. Wat ta saak docht, is wannear't de oplossing bart. As it apparaat de namme allinnich oplost wylstst de konfiguraasje tapast, is de bewarre ynskriuwing like statysk as in typt adres, en in lettere adreswiziging freget noch in tapassing. Dat it fjild in namme akseptearret, seit dy neat oer fernijing.

Behearde opset fernijt it wurk meastentiids. In DHCP-reservearring of statyske lease hâldt de Pi op ien adres, en it DNS-record folget gewoan de lease. Neat hoecht in beweegjend doel te folgjen, want it doel beweecht net.

In monitorde fernijer is it oare legitime patroan, en it hat in eigner nedich.

Set it adres fêst of rin de fernijer sels

Foar in lyts LAN is in reservearring op 'e DHCP-tsjinner de goedkeapste oplossing. Kies in adres bûten de dynamyske pool, byn it oan it MAC-adres fan 'e Pi, en befêstigje it mei ip -4 addr show dev eth0 nei de folgjende leasefernijing. Dan wiis de folgjende hop fan 'e klanten ien kear nei dat adres. No hast in stabile gateway en in record dat it beskriuwt, en dat is de oarder wêryn't de relaasje echt wurket.

As de Pi wier ferhúzje moat, hâld de rûte-reparaasje op ien plak ynstee fan elke klant mei de hân te bewurkjen. In koart skript dat oplost, ferliket en ferfangt is genôch om de stap werhellber te meitsjen:

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

It lêste kommando is de akseptaasjetest, want it prints de gateway dy't de kernel echt brûke sil. As it printe adres noch it âlde is, rûn it skript yn 'e ferkearde netwurknammeromte of hie it gjin tastimming, en de DNS-kant is irrelevant.

Kontrolearje ek de weromweis. De Pi moat witte hoe't it it kliïntsubnet berikt, en syn firewall moat it tunnelferkear tastean. In standertrûte dy't taheakke wurdt om de misferhâlding te bedekken, ferberget meastentiids it echte gat en brekt in wike letter wat oars.

Relatearre artikelen