Novirzīt statisku maršrutu uz vārtejas nosaukumu šķiet tā, it kā tam vajadzētu pārdzīvot adreses maiņu, un tas nenotiek. Nosaukums dzīvo DNS, bet maršruts sēž klienta maršrutēšanas tabulā kā skaitlisks nākamais lēciens. Kad Pi pārceļas uz citu adresi, katrs patērētājs, kas jau ir instalējis veco lēcienu, turpina sūtīt trafiku uz to pašu numuru. Neviens atrisinātājs nav pievienots pārsūtīšanas tabulai, tāpēc nekas šo ierakstu jūsu vietā nepārraksta.

DNS atbilde un maršruts ir dažādi objekti

Pieņemsim, ka jūsu Pi atbild uz vpn-gw.lan un pārsūta 10.44.0.0/16 tunelī. Klienti 192.168.30.0/24 tīklā to sasniedz ar statisku maršrutu. Kad Pi adrese pārcēlās no 192.168.30.4 uz 192.168.30.11, ieraksts sekoja sava TTL ietvaros, bet maršruti ne.

Abi skati nesaskan tā, ka to ir viegli nepamanīt, jo abi izskatās ticami, ja tos vaicā atsevišķi:

$ 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

Tikai pirmā rinda izlemj, kur paketes dodas. Otrā rinda atbild uz jautājumu, ko kodols nekad nav uzdevis. Ieraksts ar vairākiem A ierakstiem arī nekļūst par pārslēgšanās politiku kļūmes gadījumā, jo katrai adresei joprojām ir jābūt lietojamam nākamajam lēcienam tajā segmentā.

Kas paliek tabulā pēc komandas beigām

Linux maršruts ieraksta divas lietas, kas šeit ir svarīgas: nākamo lēcienu kā protokola adresi un izejas saskarni kā indeksa numuru. rtnetlink maršruta atribūti nosauc šo pirmo lauku RTA_GATEWAY, un tajā glabājas baiti. Kad ieraksts ir savā vietā, tam nav pievienots neviens TTL un neviena fona meklēšana to neatjaunina.

Tāpēc ip route add 10.44.0.0/16 via vpn-gw.lan var izskatīties strādājam. Rīks atrisina nosaukumu, kamēr komanda darbojas, ieraksta iegūto adresi un pilnībā aizmirst nosaukumu. Palaidiet ip route show 10.44.0.0/16 pēc tam, un jūs saņemsit burtisku adresi atpakaļ.

Šo uzvedību ir vērts zināt, pirms vainot tuneli.

Rīki, kas atrisina nosaukumu jūsu vietā, un kad

Daži maršrutētāji un ugunsmūri patiešām pieņem resursdatora nosaukumus maršruta vai vārtejas laukā. Svarīgi ir tas, kad notiek atrisināšana. Ja ierīce atrisina nosaukumu tikai tad, kad jūs piemērojat konfigurāciju, saglabātais ieraksts ir tikpat statisks kā ierakstīta adrese, un vēlākai adreses maiņai nepieciešama vēl viena piemērošana. Tas, ka lauks pieņem nosaukumu, neko nepasaka par atjaunināšanu.

Pārvaldītas konfigurācijas parasti sadala darbu. DHCP rezervācija vai statiska noma notur Pi vienā adresē, un DNS ieraksts vienkārši seko nomai. Nekam nav jāseko kustīgam mērķim, jo mērķis nekustas.

Uzraudzīts atjauninātājs ir otrs likumīgais modelis, un tam vajadzīgs īpašnieks.

Piespraudiet adresi vai palaidiet atjauninātāju paši

Mazam LAN tīklam rezervācija DHCP serverī ir lētākais risinājums. Izvēlieties adresi ārpus dinamiskā baseina, piesaistiet to Pi MAC adresei un apstipriniet ar ip -4 addr show dev eth0 pēc nākamās nomas atjaunošanas. Tad vienreiz vērsiet klientu nākamo lēcienu uz šo adresi. Tagad jums ir stabils vārteja un ieraksts, kas to apraksta, un tā ir kārtība, kādā šīs attiecības patiešām darbojas.

Ja Pi tiešām ir jāpārceļ, turiet maršruta labošanu vienā vietā, nevis rediģējiet katru klientu ar roku. Īss skripts, kas atrisina, salīdzina un aizstāj, ir pietiekams, lai soli padarītu atkārtojamu:

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

Pēdējā komanda ir pieņemšanas tests, jo tā izdrukā vārteju, ko kodols patiešām izmantos. Ja izdrukātā adrese joprojām ir vecā, skripts tika palaists nepareizā tīkla nosaukumtelpā vai tam nebija atļaujas, un DNS puse ir nebūtiska.

Pārbaudiet arī atgriešanās ceļu. Pi ir jāzina, kā sasniegt klientu apakštīklu, un tā ugunsmūrim ir jāatļauj tuneļa trafiks. Noklusējuma maršruts, kas pievienots neatbilstības aizsegšanai, parasti paslēpj īsto robu un pēc nedēļas salauž kaut ko citu.

Saistītie raksti