Ці абнаўляе імя хоста Pi-шлюза статычныя маршруты самастойна?

Направіць статычны маршрут на імя шлюза здаецца так, нібы ён павінен перажыць змену адрасу, але ён не перажывае. Імя жыве ў DNS, а маршрут сядзіць у табліцы маршрутызацыі кліента як лікавы наступны хоп. Калі Pi пераязджае на іншы адрас, кожны спажывец, які ўжо ўсталяваў стары хоп, працягвае слаць трафік на той самы нумар. Ніякі рэзалвер не падключаны да табліцы перасылкі, таму нішто не перапіша гэты запіс за вас.

Адказ DNS і маршрут — розныя аб’екты

Няхай ваш Pi адказвае на vpn-gw.lan і перасылае 10.44.0.0/16 у тунель. Кліенты ў 192.168.30.0/24 дасягаюць яго праз статычны маршрут. Калі адрас Pi змяніўся з 192.168.30.4 на 192.168.30.11, запіс паспеў за ім у межах свайго TTL, а маршруты — не.

Два погляды разыходзяцца так, што гэта лёгка прапусціць, бо абодва выглядаюць праўдападобна, калі запытваць іх асобна:

$ 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

Толькі першы радок вырашае, куды пойдуць пакеты. Другі радок адказвае на пытанне, якога ядро ніколі не задавала. Запіс з некалькімі A-запісамі таксама не робіцца палітыкай пераключэння пры адмове, бо кожны адрас усё роўна мусіць быць працаздольным наступным хопам у гэтым сегменце.

Што застаецца ў табліцы пасля выхаду каманды

Маршрут Linux фіксуе дзве рэчы, важныя тут: наступны хоп як адрас пратаколу і выходны інтэрфейс як нумар індэкса. атрыбуты маршрутаў rtnetlink называюць тое першае поле RTA_GATEWAY, і яно захоўвае байты. Як толькі запіс на месцы, да яго не далучаецца ніякі TTL і ніякі фонавы пошук яго не абнаўляе.

Вось чаму ip route add 10.44.0.0/16 via vpn-gw.lan можа выглядаць працаздольнай. Інструмент развязвае імя, пакуль каманда выконваецца, запісвае атрыманы адрас і цалкам забывае імя. Выканайце ip route show 10.44.0.0/16 пасля — і вы атрымаеце літаральны адрас.

Гэтыя паводзіны варта ведаць, перш чым вінаваціць тунель.

Інструменты, якія развязваюць імя за вас, і калі

Некаторыя маршрутызатары і фаерволы сапраўды прымаюць імёны хасцяў у полі маршруту або шлюза. Важна тое, калі адбываецца развязанне. Калі прылада развязвае імя толькі тады, калі вы ўжываеце канфігурацыю, захаваны запіс такі ж статычны, як набраны адрас, і пазнейшая змена адрасу патрабуе чарговага ўжывання. Тое, што поле прымае імя, нічога не кажа вам пра абнаўленне.

Кіраваныя ўстаноўкі звычайна дзеляць працу. Рэзервацыя DHCP або статычная арэнда трымае Pi на адным адрасе, а DNS-запіс проста ідзе за арэндай. Нішто не мусіць сачыць за рухомай мэтай, бо мэта не рухаецца.

Кіраваны абнаўляльнік — іншы законны шаблон, і яму патрэбен уладальнік.

Замацуйце адрас або запусціце абнаўляльнік самі

Для невялікай лакальнай сеткі рэзервацыя на DHCP-серверы — самае таннае рашэнне. Выберыце адрас па-за дынамічным пулам, прывяжыце яго да MAC-адраса Pi і пацвердзіце яго праз ip -4 addr show dev eth0 пасля чарговага абнаўлення арэнды. Потым накіруйце наступны хоп кліентаў на гэты адрас адзін раз. Цяпер у вас стабільны шлюз і запіс, які яго апісвае, — гэта той парадак, у якім сувязь і працуе.

Калі Pi сапраўды мусіць пераехаць, трымайце рамонт маршруту ў адным месцы, замест таго каб уручную правіць кожнага кліента. Кароткага скрыпта, які развязвае, параўноўвае і замяняе, дастаткова, каб зрабіць крок паўторным:

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

Апошняя каманда — гэта праверка прыёмкі, бо яна друкуе шлюз, які ядро сапраўды будзе выкарыстоўваць. Калі надрукаваны адрас усё яшчэ стары, скрыпт выканаўся ў не тым сеткавым прасторы імёнаў або не меў правоў, а бок DNS не мае значэння.

Праверце таксама зваротны шлях. Pi мусіць ведаць, як дасягнуць падсеткі кліентаў, а яго фаервол мусіць дазваляць трафік тунеля. Стандартны маршрут, дададзены, каб замазаць неадпаведнасць, звычайна хавае сапраўдную прабоіну і праз тыдзень ламае нешта іншае.