Вимикати IPv6, щоб виправити витік VPN? Краще визначте політику
Адреса link-local — не витік, і глобальний маршрут IPv6 теж. Спершу виберіть між блокуванням, перенесенням і залишенням.
Адреса з діапазону IPv6 з'являється на тестовій сторінці, тунель явно її не переносить, а найпопулярніша порада в інтернеті — вимкнути IPv6 усюди. Ця команда справді змушує панель замовкнути. Але вона також вилучає протокол, від якого може залежати мережа доступу, і залишає вас без уявлення, чи адреса була справжнім витоком, адресою інтерфейсу link-local або резолвером, що робить свою роботу. Правильне керування визначають три умови, і лише одна з них веде до блокування.
Визначте, що інструмент насправді виміряв
Найпоширеніша хибна тривога — адреса link-local, яка починається з fe80: і існує на кожному інтерфейсі з підтримкою IPv6, незалежно від того, чи машина досягає інтернету через IPv6. Вона з'являється в списках інтерфейсів і в деяких діагностиках застосунків і нічого не каже про шлях вашого трафіку.
Друга хибна тривога — унікальна локальна адреса в fc00::/7, це приватний діапазон, що використовується всередині мережі. Інструмент, який друкує кожну адресу хоста, із задоволенням перелічить її поруч із публічною. Хто читає швидко, називає це витоком і потім витрачає годину на проблему, якої немає.
Третя зовсім не хибна тривога. Глобальна адреса, яка досягає інтернету поза тунелем, і є справжній витік, і її варто виміряти, перш ніж щось вирішувати:
ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.coЯкщо перша команда друкує глобальну адресу, а третя повертає публічну адресу IPv6, що не належить тунелю, у вас є справжній шлях поза тунелем. Якщо перша не друкує нічого, крім записів link-local, витоку, який треба виправити, ніколи не було.
Керування визначають три умови
Рішення не «IPv6 добрий» чи «IPv6 поганий». Рішення в тому, у якій із трьох ситуацій ви перебуваєте, і кожна має іншу правильну відповідь з іншою ціною, якщо помилитеся.
| Situation | Correct control | Cost if you disable IPv6 instead |
|---|---|---|
| Exit has no IPv6, host does | Block IPv6 deliberately in the tunnel policy | Same visible result, no documentation of intent |
| Exit carries IPv6, host leaks | Route IPv6 into the tunnel and verify | You lose IPv6 reachability entirely |
| Access network is IPv6-only | Change nothing; use the tunnel's IPv6 | Machine loses connectivity completely |
Перший рядок — те, що люди зазвичай мають на увазі, і це законно. Клієнт, чий вихід не підтримує IPv6, не повинен тихо випускати власний трафік IPv6 хоста, бо це задокументований витік подвійного стеку. Сенс у тому, щоб блокувати його як оголошену політику, а не вимикати протокол у ядрі. Видимий результат однаковий, і лише один із них можна перевірити пізніше.
Третій рядок — місце, де загальна порада стає активно шкідливою. Мобільні оператори й деякі домашні з'єднання ведуть мережі IPv6-only з трансляцією для адрес IPv4. Приберіть там IPv6, і ви приберете єдиний транспорт, який пропонує мережа, що дає значно гіршу аварію, ніж та, яку ви усували.
Якщо у виходу немає IPv6, заблокуйте його навмисно
Віддавайте перевагу власному механізму клієнта, бо він діє рівно поки тунель піднятий і скасовується, коли той падає. OpenVPN має для цього опцію, а iptables має еквівалентне правило для інших клієнтів:
block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachableДиректива належить профілю; правило — міжмережевому екрану, який ви можете переглянути й вилучити. Обидва відмовляють закрито, що й потрібно, і обидва видимі в diff конфігурації, чого не скажеш про sysctl ядра, закопаний у стартовому скрипті.
Запишіть, чому воно там. Правило блокування без коментаря вилучить наступна людина, якій IPv6 знадобиться для чогось іншого, і тоді витік тихо повернеться.
Якщо вихід переносить IPv6, маршрутизуйте його й перевірте обидві родини
Перенесення IPv6 — краща відповідь, коли сервер його підтримує, і це не набагато складніше. Вимога: інтерфейс тунелю має адресу в цій родині, а маршрут за замовчуванням для неї веде в тунель, а не назовні фізичного інтерфейсу:
ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.coПошук маршруту — вирішальна перевірка: якщо він називає інтерфейс тунелю, трафік IPv6 переноситься. Два виклики curl потім підтверджують, що бачить кожна родина, і їхнє порівняння — це спосіб довести, що обидва шляхи тепер виходять через один і той самий вихід.
Не зупиняйтеся на успішному з'єднанні. Перепідключіть тунель і перевірте знову, бо просунутий маршрут IPv6 може загубитися під час перевстановлення, якщо сервер надсилає його лише в початковій конфігурації. Потім перевірте одну виключену адресу призначення, бо правила розділеного тунелю — це місце, де дві родини найчастіше розходяться.
Якщо мережа доступу лише IPv6, залиште її в спокої
Деякі мережі дають лише IPv6 і очікують, що пристрій досягне служб IPv4 через механізм трансляції на боці оператора. Вимкнення IPv6 на такій машині не є покращенням безпеки; воно прибирає єдиний шлях хоч кудись. Це збій, який ви самі собі влаштували заради результату тесту, який нікому не був потрібен.
Симптом цієї помилки впізнаваний і неприємний: тунель начебто встановлюється, розв'язання імен працює, а нічого не завантажується. Якщо ви бачите це після зміни IPv6, негайно відновіть налаштування й продовжте діагностику в іншому місці.
Що б ви не обрали, тримайте рішення явним у профілі або міжмережевому екрані, прив'яжіть його до того, що вихід справді підтримує, і занотуйте поведінку подвійного стеку, яку описує обговорення подвійного стеку в RFC 7359 . Оголошене блокування — це політика. Вимкнений протокол — це обхід, який ніхто не може перевірити, і з тестової сторінки вони виглядають однаково.