Упражнения с temporary IPv6 и DynDNS

В одной из локаций ростелек даёт мне аж "/56"-подсеть. А я её никак не использую. Нехорошо. Решил это исправить. Но есть проблема: она динамическая. То есть после отключения электропитания или просто после реконнекта адреса могут измениться. И зафиксировать их никак нельзя. Значит нужен Dynamic DNS.

Вопрос условно делится на три части.

1. Узнать что IP-адрес изменился.
2. Узнать новый IP-адрес.
3. Скормить его в DynDNS.

И задачка со звёздочкой: настроить временные IPv6-адреса, они же IPv6 Privacy Extensions по той же схеме. Не спрашивайте зачем. Может быть потом расскажу.

За основу настройки сети у меня взят systemd-networkd. Потому что в ifupdown-* невозможно узнать когда сеть реально настроена (нет механизма состояний), а NetworkManager меня бесит, хотя в чём-то он очень удобен. И тут кроется первая засада.

Формально для отслеживания состояния networkd существует специально обученная софтина "networkd-dispatcher". Однако она питонописная (читай: прожорливая по памяти) и выдаёт довольно куцые результаты. Поэтому была найдена другая, rustаманская, под названием "networkd-broker" (готовых deb-пакетов с ней нет, не ищите).

Вторая засада связана с той самой rustаманской софтиной: она выдает IPv6-адреса не в виде привычной строки, а в виде массива десятичных значений. То есть для дальнейшего использования его нужно ещё сконвертировать в HEX (не путать с НЁХ).

И третья засада, которую я разглядел слишком поздно. Временными адресами рулит ядро, а не networkd. Поэтому последний не присылает никаких DBus-событий по факту изменения временного адреса. Но к этому времени скрипты уже были написаны, так что переделывать я их не стал. А просто добавил ещё костылей (больше костылей богу костылей!).

Итак, скрипт для network-broker.

#!/bin/bash set -e [ "z$NWD_DEVICE_IFACE" == "zens19" ] || exit 0 [ "z$NWD_BROKER_ACTION" == "zroutable" ] || exit 0 ADDR=`echo $NWD_JSON | /usr/bin/jq 'last(.Addresses[] | select(.FlagsString=="temporary")).Address[]'` || \ ADDR=`echo $NWD_JSON | /usr/bin/jq 'last(.Addresses[] | select(.ConfigSource=="NDisc")).Address[]'` ELEM=($ADDR) ADDR="" hex=({{0..9},{a..f}}{{0..9},{a..f}}) COUNTER=0 for i in "${ELEM[@]}" ; do COUNTER=$((COUNTER+1)) ADDR+=${hex[$i]} [[ $((COUNTER % 2)) == 0 ]] || continue [[ $COUNTER -gt 15 ]] && break ADDR+=':' done

Проверяем что речь идет о нужном интерфейсе и нужном событии (ens19, routable). Парсим полученный от брокера JSON на предмет temporary-адреса. Если такового нет, берем постоянный. Дальше некий изврат по конвертации массива десятичных значений в шестнадцатеричный адрес. На выходе в переменной "${ADDR}" получаем готовый к последующему использованию адрес.

Но как я уже упоминал, при первом запуске брокер всё отдаст в лучшем виде, а вот об изменениях ничего не сообщит. Значит нужно его держать не в виде демона, а пинать принудительно. Для этого пишем сами другой [дерьмо]демон на всё том же bash-е.

#!/bin/bash /usr/bin/ip -6 monitor dev ens19 | \ while read LINE ; do [[ $LINE == *"temporary"* ]] && /usr/bin/timeout 5s /usr/bin/networkd-broker -T 2>/dev/null done

И пихаем его в systemd. Он будет дёргать нашего брокера. Вообще говоря, при таком раскладе брокер становится не особо-то и нужен. Более того, даже проще будет вместо него накорябать очередной bash-скрипт: не придется с этой конвертацией из DEC в HEX заморачиваться. Но раз уж всё равно сделал, пофиг, пусть остается как есть.

IP Monitor отслеживает изменения temporary-адреса, брокер его сообщает. Осталось запихнуть его в DynDNS. Я у себя использую knot. Мне он чё-то понравился. Процесс внесения изменений в динамическую зону в нём реализован достаточно легко и приятно по сравнению с тем же bind9. В скрипте ниже предполагается, что в ключе запуска уже присутствует правильное значение адреса, которое нам не нужно дополнительно проверять. В моём примере Primary DNS Server для зоны "foo.staser.ru" находится на той же самой виртуалке, на которой я провожу эксперименты.

#!/bin/bash [ -z "$1" ] && exit 0 /usr/bin/knsupdate << END_SCRIPT server 127.0.0.1 zone foo.staser.ru origin foo.staser.ru ttl 1800 update delete @ 300 AAAA update add @ 10 AAAA $1 send quit END_SCRIPT

Готово. Вообще говоря, IPv6 Privacy Extensions по-хорошему совсем не предназначены для того, чтобы навешивать на них какие-либо сервисы. Более того, прежний временный адрес не удалится до тех пор, пока с его участием имеются какие-либо активные соединения. Возникает неиллюзорный риск поиметь на интерфейсе чёртову тонну таких временных адресов. Так что вот этот мой псто смело можно относить к категории "потные извращения".

Но раз я подобным озаботился, значит зачем-то оно мне стало нужно... пусть будет интрига.