IPv6 через тунель OpenVPN: прохід домашнім маршрутизатором

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

Почніть з клієнта

Подивіться на клієнта, перш ніж торкатися сервера. ip -6 addr має показувати адресу тунелю з пулу, а ip -6 route — проштовхнутий префікс, що вказує на тунельний пристрій. Коли адреса є, а маршруту немає, проштовхування відсутнє або клієнт його проігнорував. Коли немає ні того, ні іншого, сервер взагалі нічого не призначив.

Потім перевірте, що клієнт думає про зовнішній світ. Маршрут за замовчуванням через тунель вимагає всього трафіку IPv6, тоді як маршрут для 2000::/3 вимагає лише глобальний unicast. Обидва можуть бути правильними, і вони відповідають на різні питання про витік.

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

Перевірте пул, який сервер справді може маршрутизувати

Сервер може виділяти лише з префікса, який він справді контролює. Якщо постачальник делегує /56, залиште один /64 для тунелю, а решту — для LAN. Там, де постачальник віддає на WAN лише один /64 і більше нічого не маршрутизує, залиште префікс LAN у спокої й дайте тунелю унікальний локальний діапазон, прийнявши, що клієнти не матимуть глобального виходу.

Пул і проштовхування йдуть разом. server-ipv6 2001:db8:80:10::/64 призначає адреси, а push "route-ipv6 2000::/3" каже клієнтам, що надсилати в тунель. Проштовхування 2000::/3 покриває глобальний unicast і залишає діапазони link-local і multicast поза тунелем.

Запишіть вибраний префікс у журнал розгортання. Той, хто наступного разу змінить передачу від постачальника, повинен знати, який /64 тунель уже займає.

Увімкніть пересилання для другої родини

Пересилання IPv4 не означає пересилання IPv6. Задайте net.ipv6.conf.all.forwarding=1 і повторіть усе, що вже дозволяє політика FORWARD для IPv4. На маршрутизаторі, чий ланцюг FORWARD за замовчуванням відкидає, відсутній набір правил виглядає точно як мертвий тунель.

Рукостискання проходить, клієнт отримує адресу, а назад нічого не приходить. Додайте правила для обох напрямків і для плеча WAN, бо тунель, який досягає LAN, але не інтернету, провалює третій тест. Після невдалої спроби подивіться на лічильники ланцюга, бо правило, яке жодного разу не збіглося, — це інша проблема, ніж те, що збіглося й відкинуло.

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

Один побічний ефект ловить тих, хто зрештою звинувачує тунель. Увімкнення пересилання змушує ядро пропускати налаштування адреси через Router Advertisement, якщо не сказати інакше, і вивчений так маршрут за замовчуванням зникає разом із нею. Або закріпіть явний маршрут за замовчуванням на інтерфейсі WAN, або навмисно задайте там accept_ra рівним 2. Після будь-якої зміни переконайтеся, що маршрутизатор усе ще має робочий шлях IPv6 назовні, перш ніж знову тестувати клієнтів.

Відповідайте на виявлення сусідів, коли верхня сторона не маршрутизує

Обладнання вище за течією іноді вважає делегований /64 таким, що належить його власному каналу, і відмовляється маршрутизувати будь-який підпрефікс до скриньки VPN. Коли це трапляється, щось має відповідати на запити сусідів для кожної клієнтської адреси окремо.

OpenVPN надає призначену адресу обробнику client-connect, тож записи можуть іти за справжнім пулом, а не за списком, який ведуть вручну. Обробник додає ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, а відповідний обробник client-disconnect його видаляє. Без видалення таблиця проксі старіє, і пізніший клієнт може успадкувати запис для адреси, якої він ніколи не отримував. Підтвердьте стан за допомогою ip -6 neigh show proxy.

Ставтеся до проксі як до обхідного рішення. Статичний маршрут для /64 тунелю, спрямований на маршрутизатор, переживає зміни клієнтів і взагалі не потребує привілейованого обробника оболонки.

Пройдіть шлях назовні, стрибок за стрибком

Перевіряйте назовні в три кроки: спершу адреса тунелю маршрутизатора, потім хост у LAN і третім публічне призначення через traceroute6. Пул доводить перший, пересилання й міжмережевий екран LAN — другий, а зворотний шлях через верхню сторону — третій. Кожна невдача звужує пошук до одного пристрою, а не відкриває заново весь дизайн.

Стежте за MTU тунелю, бо маршрутизатори IPv6 на шляху не фрагментуватимуть за вас. Завеликий MTU проявляється як помилка packet-too-big і застряглий TLS, а не як чистий збій. Задайте його явно й перевірте з навантаженням, близьким до межі.