- Почему IPv6-прокси «умирает» после смены префикса: диагностика по traceroute и whois

Почему адрес перестаёт работать без видимых причин

Провайдер выдал /64. Ты настроил прокси, всё летает. Через месяц — тишина. Сервис отвечает по SSH, но клиенты получают таймаут. Логи пустые, интерфейс поднят, маршрут есть. Классическая ситуация: префикс сменился, а конфиг остался на старом адресе.

IPv6 не использует NAT как в v4. Адрес в конфиге — это не «внутренний», он маршрутизируется глобально. Когда провайдер меняет delegated prefix (обычно по DHCPv6-PD), старый адрес становится невалидным снаружи. Пакеты доходят до границы провайдера и умирают. Внутри сети всё работает — отсюда и путаница.

Провайдеры меняют префикс по разным причинам: переподключение PPPoE, обновление биллинга, миграция на другое оборудование, смена ASN. У некоторых это происходит при каждом переподключении сессии. Другие держат префикс годами, а потом меняют разом — и половина клиентов не замечает, пока не отвалится.

Что показывает traceroute, когда префикс ушёл

traceroute по IPv6 — первый инструмент. Запускай с внешней точки, не изнутри. Изнутри ты увидишь свой же маршрутизатор и решишь, что всё хорошо.

```bash

traceroute6 -n -m 15 2001:db8:abcd::10

```

Ответ обрывается на хопе провайдера. Дальше — звёздочки. Это значит: пакет ушёл, но обратно не вернулся. Либо адрес уже не принадлежит твоей сети, либо провайдер дропает трафик к невалидному префиксу.

Смотри на последний ответивший хоп. Если это шлюз провайдера (обычно что-то вроде `2a00:...::1`), значит маршрут до тебя потерян. Провайдер не знает, куда слать пакеты для `2001:db8:abcd::/64`. Твой роутер, возможно, всё ещё держит старый адрес на интерфейсе, но апстрим уже перенаправил маршрут на новый префикс.

Полезно сравнить с трассировкой до рабочего адреса в той же сети. Если новый адрес отвечает, а старый — нет, вопрос закрыт: префикс сменился.

```bash

for addr in 2001:db8:abcd::10 2001:db8:ffff::10; do

echo "=== \$addr ==="

traceroute6 -n -m 10 -q 1 "\$addr"

done

```

whois: проверка принадлежности префикса

whois по IPv6-адресу покажет, кому принадлежит блок. Если префикс сменился, старый адрес будет числиться за провайдером, но уже в другом пуле — или вообще перейдёт к другой организации.

```bash

whois -h whois.ripe.net 2001:db8:abcd::10

```

В выводе смотри поля `inet6num`, `netname`, `org`, `country`. Если `inet6num` не совпадает с твоим выделенным блоком — адрес больше не твой. Бывает, что провайдер выдал /64, а whois показывает /32 родительского блока. Это нормально: делегирование внутри провайдера не всегда отражается в RIR.

Сравни `route6` объекты. Если твой префикс раньше был в `route6`, а теперь там другой — маршрут переназначен.

```bash

whois -h whois.ripe.net -i origin AS12345 | grep -A2 route6

```

Это покажет все маршруты, анонсируемые твоим провайдером. Ищи свой префикс. Если его нет — провайдер его больше не анонсирует.

DHCPv6-PD: как отследить смену префикса

Префикс приходит по DHCPv6 Prefix Delegation. Клиент (роутер) запрашивает у провайдера пул, получает /56 или /64, раскидывает по интерфейсам. Когда сессия переустанавливается, провайдер может выдать другой префикс.

Проверь текущий delegated prefix:

```bash

ip -6 addr show dev eth0 | grep inet6

ip -6 route show default

```

Если в `inet6` адрес не совпадает с тем, что прописан в конфиге прокси — вот и причина. Роутер получил новый префикс, а сервис слушает старый адрес. Ядро не знает, что старый адрес больше не валиден: он остаётся на интерфейсе, пока кто-то его не удалит.

Логи DHCPv6-клиента покажут момент смены:

```bash

journalctl -u dhcpcd --since "7 days ago" | grep -i prefix

```

Ищи строки вида `delegated prefix changed` или `new prefix`. Время смены совпадёт с моментом, когда клиенты начали жаловаться.

Кейс: nginx на старом адресе после переподключения PPPoE

Сервер на Debian 12, nginx 1.24, IPv6-прокси для внешних клиентов. Провайдер — PPPoE с динамическим префиксом. После переподключения сессии (обрыв линии, перезагрузка модема) префикс сменился с `2001:db8:1::/64` на `2001:db8:2::/64`.

nginx слушал `[2001:db8:1::10]:443`. Клиенты получали `connection timed out` через 30 секунд (TCP SYN retransmit). Внутри сети сервис отвечал: `curl -6 http://[2001:db8:1::10]` с самого сервера работал. Снаружи — нет.

Причина: PPPoE-сессия переустановилась, dhcpcd получил новый префикс, ядро добавило новый адрес на `ppp0`, но старый остался. nginx не перечитал конфиг. Маршрут к старому префиксу на стороне провайдера исчез — пакеты дропались на границе.

Решение: nginx слушать `[::]:443` вместо конкретного адреса. Ядро само выберет доступный. Плюс скрипт, который при смене префикса перезагружает nginx:

```bash

!/bin/bash

OLD_PREFIX_FILE=/var/run/current_prefix

NEW_PREFIX=\$(ip -6 addr show dev ppp0 scope global | awk '/inet6/{print \$2}' | head -1 | cut -d: -f1-4)

if [ -f "\$OLD_PREFIX_FILE" ] && [ "\$(cat \$OLD_PREFIX_FILE)" != "\$NEW_PREFIX" ]; then

systemctl reload nginx

echo "\$NEW_PREFIX" > "\$OLD_PREFIX_FILE"

logger "IPv6 prefix changed to \$NEW_PREFIX, nginx reloaded"

fi

```

Запускать по cron каждые 5 минут или повесить на hook dhcpcd.

Кейс: BGP-анонс без обновления route6

Своя AS, свой /48, анонсируется через BGP. Провайдер сменил upstream-провайдера, и старый `route6` объект в RIPE остался. Новый провайдер анонсирует префикс, но фильтры на стороне пиров отбрасывают его: нет `route6` с правильным origin.

Симптом: traceroute обрывается на разных точках в зависимости от географии. Из Европы работает, из Азии — нет. `whois` показывает, что `route6` привязан к старой AS.

Причина: RPSL-объекты не обновляются автоматически. Нужно вручную создать новый `route6` с корректным `origin: AS<новая>`, либо обновить существующий.

Проверка:

```bash

whois -h whois.ripe.net 2001:db8:abcd::/48

```

Смотри `origin`. Если AS не совпадает с той, через которую идёт анонс — фильтры на многих пирах (особенно с strict RPKI) дропнут маршрут. RPKI ROA тоже нужно обновить: подписать новый ROA с правильной AS.

Кейс: клиент застрял на старом адресе в DNS

Прокси-сервис, клиенты подключаются по домену. AAAA-запись указывала на старый адрес. Префикс сменился, AAAA не обновился. Клиенты резолвят домен, получают мёртвый адрес, стучатся в никуда.

Проблема усугубляется TTL. Если AAAA-запись имела TTL 3600, клиенты кэшировали старый адрес на час после смены. Некоторые резолверы игнорируют TTL и держат записи дольше.

Причина: скрипт обновления DNS не сработал. Обычно это ddns-клиент, привязанный к интерфейсу, а не к префиксу. При смене префикса интерфейс остаётся тем же, ddns-клиент не видит изменений.

Решение: мониторить именно IPv6-адрес, а не состояние интерфейса. Обновлять AAAA при любом изменении. TTL для AAAA — 300 секунд, не больше.

```python

import subprocess

import requests

def get_current_ipv6(iface="ppp0"):

out = subprocess.check_output(["ip", "-6", "addr", "show", "dev", iface]).decode()

for line in out.splitlines():

if "inet6" in line and "scope global" in line:

return line.split()[1].split("/")[0]

return None

def update_dns(ip, zone, record, token):

url = f"https://api.cloudflare.com/client/v4/zones/{zone}/dns_records/{record}"

headers = {"Authorization": f"Bearer {token}", "Content-Type": "application/json"}

data = {"type": "AAAA", "content": ip, "ttl": 300}

r = requests.patch(url, json=data, headers=headers)

return r.status_code

current = get_current_ipv6()

if current:

print(f"current: {current}, dns update: {update_dns(current, 'ZONE_ID', 'RECORD_ID', 'TOKEN')}")

```

Таблица: типичные симптомы при смене префикса

| Симптом | Что показывает traceroute | Что показывает whois | Причина |

|---|---|---|---|

| Таймаут снаружи, работает изнутри | Обрыв на шлюзе провайдера | Старый `inet6num` | Адрес не маршрутизируется |

| Работает из Европы, не работает из Азии | Обрыв на разных хопах | `origin` не совпадает с AS | RPKI/фильтры BGP |

| Работает после перезагрузки, потом отваливается | Плавающий обрыв | Префикс меняется в whois | DHCPv6-PD выдаёт новый пул |

| DNS резолвится, соединение не устанавливается | Обрыв на последнем хопе | Адрес чужой | AAAA не обновился |

Как автоматизировать детект смены префикса

Ручная проверка — это костыль. Нужен мониторинг. Простейший вариант: cron каждые 5 минут сравнивает текущий префикс с сохранённым и шлёт алерт при изменении.

```bash

!/bin/bash

STATE=/var/lib/ipv6-prefix.state

CURRENT=\$(ip -6 route show default | awk '{print \$3}' | head -1)

if [ ! -f "\$STATE" ]; then

echo "\$CURRENT" > "\$STATE"

exit 0

fi

SAVED=\$(cat "\$STATE")

if [ "\$CURRENT" != "\$SAVED" ]; then

echo "IPv6 gateway changed: \$SAVED -> \$CURRENT" | mail -s "IPv6 prefix alert" ops@example.com

echo "\$CURRENT" > "\$STATE"

systemctl reload nginx

fi

```

Лучше — мониторить внешний доступ. Скрипт с внешнего хоста раз в минуту стучится на прокси и проверяет HTTP-код. Если 3 раза подряд таймаут — алерт. Это ловит не только смену префикса, но и другие проблемы.

Почему «просто перезагрузить» не всегда помогает

Перезагрузка сервера подтянет новый адрес, если DHCPv6-клиент настроен правильно. Но если адрес прописан статически в конфиге сети — ничего не изменится. Сервер поднимется со старым адресом, который уже не маршрутизируется.

Проверь `/etc/network/interfaces` или `netplan` на предмет статических IPv6. Если там жёстко прописан адрес из старого префикса — это грабли, на которые наступают регулярно. Статика уместна только при статическом префиксе от провайдера.

Второй момент: некоторые провайдеры выдают префикс с длинным lease time (например, 7 дней). После смены префикса старый адрес может оставаться на интерфейсе до истечения lease. Ядро считает его deprecated, но сервисы продолжают на него биндиться.

Флаг `deprecated` в `ip -6 addr` — сигнал, что адрес скоро уйдёт. Сервисы должны слушать `::`, а не конкретный адрес, чтобы избежать этой ловушки.

Инструменты для быстрой диагностики

Помимо traceroute6 и whois, полезны:

- `ping6 -I ` — проверить, уходит ли трафик через нужный интерфейс.

- `ip -6 neigh` — посмотреть соседей, найти залипшие записи.

- `ss -6 -tlnp` — какие сервисы слушают IPv6 и на каких адресах.

- `tcpdump -i any -n ip6` — увидеть, доходят ли пакеты до интерфейса.

Быстрый чек-лист при жалобе «не работает IPv6»:

```bash

ip -6 addr show

ip -6 route show

ss -6 -tlnp

ping6 -c 3 2001:4860:4860::8888

traceroute6 -n -m 10 2001:4860:4860::8888

```

Если ping до `2001:4860:4860::8888` (Google DNS) проходит, а до твоего адреса снаружи — нет, проблема в маршрутизации префикса. Если ping не проходит вообще — проблема на стороне провайдера или локальной сети.

Что делать, чтобы не повторялось

Слушать `[::]` во всех сервисах. Не прописывать IPv6-адреса статически, если префикс динамический. Мониторить смену префикса и автоматически перезагружать конфиги. Держать TTL DNS низким. Обновлять RPSL и RPKI при смене upstream.

Провайдеры редко предупреждают о смене префикса. Некоторые — вообще никогда. Рассчитывать на их уведомления не стоит. Собственный мониторинг — единственный способ узнать о проблеме раньше клиентов.

Сервис вроде lexic.ml держит IPv6-прокси с 2015 года и за это время пережил не одну смену префикса у апстримов — именно потому, что детект и переключение автоматизированы, а не делаются руками по звонку.