Päivittääkö Pi-yhdyskäytävän isäntänimi staattiset reitit itsestään?

Pi-yhdyskäytäväsi DNS-nimi ei koskaan kirjoita uudelleen asennettua seuraavaa hyppyä. Katso, mitä ydin tallentaa ja kenen on päivitettävä reitti.

Staattisen reitin osoittaminen yhdyskäytävän nimeen tuntuu siltä, että sen pitäisi kestää osoitteenmuutos, eikä se kestä. Nimi elää DNS:ssä, kun taas reitti istuu asiakkaan reititystaulussa numeerisena seuraavana hyppynä. Kun Pi siirtyy toiseen osoitteeseen, jokainen kuluttaja, joka on jo asentanut vanhan hypyn, lähettää liikennettä edelleen samaan numeroon. Mikään ratkaisin ei ole kytketty edelleenlähetystauluun, joten mikään ei kirjoita sitä merkintää puolestasi uudelleen.

DNS-vastaus ja reitti ovat eri kohteita

Sanotaan, että Pi vastaa osoitteeseen vpn-gw.lan ja välittää 10.44.0.0/16 tunnelin. Asiakkaat verkossa 192.168.30.0/24 saavuttavat sen staattisen reitin kautta. Kun Pi:n osoite siirtyi osoitteesta 192.168.30.4 osoitteeseen 192.168.30.11, tietue seurasi TTL:nsä puitteissa eivätkä reitit.

Näkymät ovat ristiriidassa tavalla, joka on helppo jättää huomaamatta, koska molemmat näyttävät uskottavilta, kun niitä kysyy erikseen:

$ 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

Vain ensimmäinen rivi päättää, mihin paketit menevät. Toinen rivi vastaa kysymykseen, jota ydin ei koskaan kysynyt. Tietue, jossa on useita A-tietueita, ei myöskään muutu vikasietotilaksi, koska jokaisen osoitteen on silti oltava käyttökelpoinen seuraava hyppy kyseisessä segmentissä.

Mitä tauluun jää, kun komento päättyy

Linux-reitti tallentaa kaksi tässä merkityksellistä asiaa: seuraavan hypyn protokollaosoitteena ja lähtöliitännän indeksinumerona. rtnetlinkin reittimääritteet nimeävät tuon ensimmäisen kentän RTA_GATEWAY, ja se pitää sisällään tavuja. Kun merkintä on paikallaan, siihen ei ole liitetty TTL:ää eikä mikään taustahaku päivitä sitä.

Siksi ip route add 10.44.0.0/16 via vpn-gw.lan voi näyttää toimivan. Työkalu ratkaisee nimen komennon aikana, kirjoittaa tuloksena olevan osoitteen ja unohtaa nimen kokonaan. Aja ip route show 10.44.0.0/16 sen jälkeen ja saat takaisin kirjaimellisen osoitteen.

Tämä käytös kannattaa tuntea ennen kuin syyttää tunnelia.

Työkalut, jotka ratkaisevat nimen puolestasi, ja milloin

Jotkin reitittimet ja palomuurit todella hyväksyvät isäntänimiä reitti- tai yhdyskäytäväkentässä. Ratkaisevaa on, milloin ratkaisu tapahtuu. Jos laite ratkaisee nimen vain, kun otat kokoonpanon käyttöön, tallennettu merkintä on yhtä staattinen kuin kirjoitettu osoite, ja myöhempi osoitteenmuutos vaatii vielä yhden käyttöönoton. Se, että kenttä hyväksyy nimen, ei kerro sinulle mitään päivittämisestä.

Hallitut asennukset jakavat työn yleensä. DHCP-varaus tai staattinen vuokraus pitää Pi:n yhdessä osoitteessa, ja DNS-tietue seuraa yksinkertaisesti vuokrausta. Mitään ei tarvitse seurata liikkuvaa kohdetta, koska kohde ei liiku.

Valvottu päivittäjä on toinen laillinen malli, ja se tarvitsee omistajan.

Kiinnitä osoite tai aja päivittäjä itse

Pienelle lähiverkolle varaus DHCP-palvelimella on halvin korjaus. Valitse osoite dynaamisen altaan ulkopuolelta, sido se Pi:n MAC-osoitteeseen ja vahvista se ip -4 addr show dev eth0:llä seuraavan vuokrauksen uusimisen jälkeen. Sitten osoita asiakkaiden seuraava hyppy tuohon osoitteeseen kerran. Nyt sinulla on vakaa yhdyskäytävä ja sitä kuvaava tietue, ja se on se järjestys, jossa suhde todella toimii.

Jos Pi:n on todella siirryttävä, pidä reitin korjaus yhdessä paikassa sen sijaan, että muokkaisit jokaista asiakasta käsin. Lyhyt skripti, joka ratkaisee, vertaa ja korvaa, riittää tekemään vaiheesta toistettavan:

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

Viimeinen komento on hyväksymistesti, koska se tulostaa yhdyskäytävän, jota ydin todella käyttää. Jos tulostettu osoite on yhä vanha, skripti ajettiin väärässä verkon nimiavaruudessa tai siinä ei ollut käyttöoikeutta, ja DNS-puoli on merkityksetön.

Tarkista myös paluureitti. Pi:n on tiedettävä, miten asiakasaliverkkoon päästään, ja sen palomuurin on sallittava tunnelin liikenne. Epäsuhdan peittämiseksi lisätty oletusreitti yleensä kätkee todellisen aukon ja rikkoo jotain muuta viikkoa myöhemmin.

Aiheeseen liittyvät artikkelit