Додаємо приватний IPv6 до лабораторії OpenVPN, по одній контрольній точці

Залиште зовнішній транспорт на IPv4 і розширте внутрішній план. П'ять контрольних точок: префікси, помічник, просування маршруту, пересилання та перевірка з боку клієнта.

У вас уже є клієнт, який підключається через IPv4 і досягає приватного робочого навантаження IPv4 за сервером. Мета — досягти приватного робочого навантаження IPv6 через той самий тунель, не торкаючись зовнішнього транспорту. Цей порядок важливий: зовнішній шлях залишається IPv4, а змінюються лише внутрішній план адрес, маршрут клієнта і зворотний шлях від сервера до LAN. П'ять контрольних точок, у кожній є щось конкретне, що варто перевірити, перш ніж рухатися далі.

Перша контрольна точка: з'єднання, яке вже працює

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

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

Друга контрольна точка: виберіть внутрішні префікси

Виберіть ULA /48 для майданчика і виріжте з неї дві /64: одну для клієнтів тунелю, одну для сегмента LAN з робочим навантаженням IPv6. Згенеруйте 40-бітний глобальний ID замість копіювання прикладу префікса, і перевірте обидві підмережі проти кожної мережі, яку майданчик уже маршрутизує:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

Дві незалежні /64 не дають вирізати пул клієнтів із сегмента LAN, що важливо пізніше, коли ви пишете зворотний маршрут. Значення вище — один опрацьований приклад, а не префікс для повторного використання.

Третя контрольна точка: додайте помічник і просування маршруту

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

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

Перший — зручний помічник, який налаштовує інтерфейс і пул клієнтів. Другий називає призначення в LAN, куди клієнт має потрапити. Призначення клієнтові адреси IPv6 не говорить йому, які мережі є за сервером, тому потрібні обидва рядки.

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

Четверта контрольна точка: пересилання і маршрут відповіді

Увімкніть пересилання IPv6 на сервері через штатного власника конфігурації системи, а не одноразовим записом під час роботи, який ви забудете. Форма під час роботи корисна для швидкої перевірки. Постійна конфігурація належить до drop-in файлу, який читає мережевий власник дистрибутива:

sysctl -w net.ipv6.conf.all.forwarding=1

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

Далі дайте LAN зворотний маршрут до пулу тунелю. Шлюз IPv6 робочого навантаження — це маршрутизатор LAN, а не сервер VPN, тож маршрут належить тому маршрутизатору і вказує на адресу сервера в LAN:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

Збережіть типи ICMPv6, потрібні каналу, зокрема зворотний зв'язок щодо MTU шляху. Правило брандмауера IPv4 не означає правило IPv6, а суцільне блокування IPv6 ламає виявлення сусідів так, що це виглядає як збій маршрутизації.

П'ята контрольна точка: прочитайте клієнта, потім перевірте

Перепідключіть клієнта і прочитайте адреси, які він справді отримав, замість того щоб виводити їх з адреси помічника на сервері. Список інтерфейсів показує обидві родини на одному пристрої:

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

Маршрут, який вибирає тунель, доводить, що клієнт знає, куди надіслати пакет. Він не доводить, що сервер його пересилає, що маршрутизатор LAN має зворотний маршрут або що застосунку дозволено відповідати.

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

Публікуйте запис AAAA лише тоді, коли шлях IPv6 відповідає від початку до кінця. DNS, запитаний через IPv4, усе ще може повернути адресу IPv6, тож розв'язуване ім'я не є доказом, що щось слухає. Настанови RFC 4193 щодо ULA охоплюють генерацію глобального ID, який робить ці префікси вашими, а не копією.

Схожі статті