VPN з подвійним стеком: родину адрес вибирає клієнт, а не ви

Тунель піднято, сайти IPv4 завантажуються, а одне ім'я хоста завершується тайм-аутом. Негайний висновок — VPN зламано або облікові дані неправильні, і зазвичай ні те, ні інше не правда. Ім'я повернуло і адресу IPv4, і адресу IPv6, застосунок вибрав одну, і лише один із цих кандидатів мав робочий шлях. Рішення про вибір ухвалив клієнт; тунель просто не покривав те, що він вибрав.

Вибір — не обіцянка покриття

Вибір адреси за замовчуванням, описаний у RFC 6724, визначає, яку пару джерела й призначення хост віддає перевагу, коли доступно кілька. Happy Eyeballs додає зверху стратегію з'єднання: він починає спроби в обох родинах і залишає ту, що відповість першою, щоб користувач не чекав завершення тайм-ауту зламаної родини.

Жоден із механізмів не створює маршрут. Якщо ваш тунель несе лише IPv4, кандидат AAAA залишається законним призначенням, яке клієнт може спробувати, і збій виявляється як повільне завантаження, а не як помилка, бо браузер відкотився. Користувач повідомляє про повільний сайт, а не про зламаний, і тікет підтримки успадковує цю невизначеність. Відтворіть це з фіксованою родиною — і звіт стане конкретним.

Саме через цей відкат симптом несогласований між застосунками. Браузер приховує затримку; клієнт командного рядка з фіксованою родиною одразу показує реальний збій.

З'ясуйте, яку родину запит насправді використав

Почніть з імені, а не з тунелю. Запитайте обидва типи записів і запишіть, що повернулося:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

Якщо запит v4 успішний, а запит v6 завершується невдачею, ви відтворили проблему в налагоджуваній формі. Якщо обидва успішні з оболонки, а браузер усе одно зазнає невдачі, подивіться на власний резолвер застосунку або кешовану відповідь, перш ніж чіпати тунель.

Тримайте родину й призначення у своїх нотатках. Тікет «сайт не завантажується через VPN» ніхто не зможе перевірити, а тікет «AAAA не працює, A працює» вказує на конкретний маршрут.

Перевірте маршрут для цієї родини

Для збійної родини запитайте ядро, який шлях воно використає, і порівняйте його з налаштованими адресами тунелю. У Linux ip -6 route get для призначення показує інтерфейс і джерело, які були б вибрані.

Потім перевірте сам тунель. Піри WireGuard несуть список дозволених IP, а запис для 0.0.0.0/0 нічого не каже про IPv6. Якщо в списку піра немає префікса IPv6, у клієнта немає причин надсилати трафік AAAA в тунель, і пакет виходить туди, куди хост надіслав би його інакше.

Правила брандмауера й політика NAT заслуговують такої самої перевірки для кожної родини. Правило, написане для IPv4, не покриває IPv6 на жодній платформі, і це найчастіша причина, чому одна родина працює, а інша ні.

Не вимикайте IPv6, щоб спростити скриншот

Вимкнення IPv6 у всій системі прибере симптом і залишить вас без діагностики. Воно також ламає будь-яке призначення, що працює лише через IPv6, і приховує ту саму помилку для наступного застосунку. Якщо машині справді не слід використовувати IPv6, це свідома політика з власником і тестом. Вимкнення під час інциденту — ні те, ні інше.

Вирішіть, що клієнт має робити з родиною, і налаштуйте це явно: проведіть її через тунель або заблокуйте в підтримуваний спосіб, щоб вибір ніколи не пропонував недосяжного кандидата. Обидва варіанти — законні проєкти. Глобальне вимкнення — жоден із них, бо це взагалі не проєкт.

Що вказати в тікеті

Запишіть чотири речі: ім'я хоста, родину, яка не спрацювала, маршрут, вибраний ядром, і результат запиту, специфічного для родини. Цього набору достатньо, щоб хтось інший відтворив збій, не вгадуючи, який із двох шляхів ви мали на увазі.

Правила вибору адрес RFC 6724 пояснюють, чому клієнт віддав перевагу саме цьому кандидату, а RFC 8305 пояснює гоночну поведінку, що приховала затримку. Жодне з них не прокладе маршрут за вас, і саме це має зробити тунель.