Обновляет ли имя хоста шлюза Pi статические маршруты само?

DNS-имя шлюза 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 должен знать, как достичь клиентской подсети, а его межсетевой экран должен разрешать трафик туннеля. Маршрут по умолчанию, добавленный, чтобы скрыть несоответствие, обычно прячет настоящую дыру и через неделю ломает что-то другое.

Похожие статьи