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 позбавляють наступну людину перезапуску трьох демонів, щоб знайти той, який мав значення.