IPv6-выход умирает после перезапуска OpenVPN: проверьте, кому принадлежит префикс
IPv6 умирает после пересоздания туннеля. Определите, кому принадлежат делегированный префикс, адреса клиентов и обратный маршрут, прежде чем что-либо перезапускать.
IPv6 перестаёт пропускать трафик в тот момент, когда OpenVPN перезапускается, а IPv4 продолжает работать. Интерфейс туннеля был пересоздан, и что-то другое, управлявшее его состоянием IPv6, потеряло либо адрес, либо маршрут, который делает префикс доступным. Задействованы три отдельные части состояния, и у каждой свой владелец: делегированный префикс провайдера и срок его жизни, адреса, выданные клиентам VPN, и вышестоящий маршрут, который возвращает этот клиентский префикс серверу. Определите владельца каждой части, прежде чем трогать любой демон, потому что перезапуск не того скрывает проблему на день и возвращает её при следующем подключении.
Три части состояния IPv6, три владельца
| State | Typical owner | What breaks when it is wrong |
|---|---|---|
| Delegated prefix and lifetime | Upstream router or provider via DHCPv6-PD | Clients keep addresses that the upstream no longer routes |
| Client addresses inside the tunnel | OpenVPN server config or a delegation daemon | No global address, or an address outside the routed prefix |
| Return route for the client prefix | Upstream router, or the server's own routing table | Outbound works, replies never arrive |
Адрес с глобальной областью действия внутри туннеля сам по себе недостаточен. Маршрутизаторы выше по-прежнему должны отправлять этот префикс обратно к серверу VPN, и они не станут этого делать только потому, что у сервера случайно есть адрес из него.
Поэтому и копировать публичный /64 в пул туннеля рискованно. Префикс, маршрутизированный на сервер, — не то же самое, что префикс, который вышестоящая сторона считает on-link, и обнаружение соседей эту дыру не закроет.
Прочитайте состояние сервера, прежде чем что-либо менять
Снимите состояние дважды: один раз, когда IPv6 работает, и один раз после перезапуска, затем сравните. Представлений только для чтения достаточно, и в окно обслуживания они ничего не стоят:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingИщите три конкретных различия: исчезнувший маршрут, адрес, перешедший в устаревший или недействительный срок жизни, и префикс, изменившийся после повторного делегирования, тогда как конфигурация VPN всё ещё анонсирует старый.
Если адрес исчез, а префикс не изменился, демон, который его назначает, перестал управлять интерфейсом. Если префикс изменился, а адреса нет, конфигурация клиента устарела. Оба сбоя выглядят из браузера одинаково и не имеют ничего общего.
Решите, должен ли dhcpcd управлять туннелем
dhcpcd умеет обнаруживать интерфейсы и делегировать части префикса DHCPv6 нижестоящим интерфейсам, а его конфигурация может явно называть цели делегирования. Без явной цели его документированное поведение может затрагивать другие интерфейсы, и именно так туннель получает адрес, которого никто не планировал.
Два условия должны подтолкнуть вас оставить статическую адресацию туннеля за OpenVPN: сервер проталкивает фиксированные адреса в своей конфигурации, и имя туннеля меняется при переподключении. Если верно и то и другое, намеренно исключите туннель из демона делегирования, с комментарием, объясняющим почему.
Если же делегирование в туннель намеренное, реализуйте обработку изменения префикса. Это значит реагировать, когда делегированный префикс или срок его жизни меняется, обновлять анонсируемый сервером клиентский префикс и снова добавлять маршрут. Исключение интерфейса в такой схеме убирает единственный компонент, который знает о новом префиксе.
Перезапуск dhcpcd может выглядеть как исправление, потому что он пересоздаёт состояние, но он также продлевает или отзывает конфигурацию для интерфейсов, о которых вы не думали. Такое восстановление не делает его обязательным после каждого перезапуска VPN. Он также сбрасывает счётчики, которые вы использовали как доказательство. Предпочитайте точечную перезагрузку того интерфейса, который вы действительно изменили.
Проверяйте IPv6 отдельно от IPv4 NAT
Убедитесь, что пересылка включена и что вышестоящий маршрут указывает на фактический префикс клиента, затем установите новое разрешённое соединение IPv6. Проверьте и собственную таблицу маршрутов IPv6 клиента, потому что клиент с публичным адресом не доказывает, что его запрос шёл через туннель.
Маскирование IPv4 решает другую задачу: обратный путь для частных источников. Для отозванного префикса IPv6 оно ничего не делает, и его добавление не вернёт IPv6.
Завершите реестром владельцев: какой компонент делегирует префикс, какой назначает адреса клиентов, какой держит обратный маршрут и что происходит с каждым при переподключении. Четыре строки в runbook избавляют следующего человека от перезапуска трёх демонов, чтобы найти тот, который имел значение.