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