Чому ваша ВМ у GCP не може відповісти на пул IPv6 OpenVPN

Ваш клієнт VPN на IPv6 досягає робочого навантаження, робоче навантаження відповідає в тунель, а відповідь так і не надходить. Перший інстинкт — звинувачувати міжмережевий екран або тунель, і зазвичай жоден із них не винен. Адреса, яку видає OpenVPN, — це внутрішня мережа, що існує лише всередині тунелю; Google Cloud гадки не має, що fd42:90::/64 має бути за однією конкретною ВМ, доки ви йому не скажете.

Цей факт мають засвоїти дві окремі системи, і лише одна з них — OpenVPN. VPC потрібен маршрут, перш ніж він зможе щось надіслати назад, а ВМ має бути дозволено пересилати те, що надходить. Помиліться в будь-якій половині — і симптом виглядатиме однаково.

Пул — це внутрішня мережа, а не підмережа

OpenVPN може видавати адреси IPv6 з діапазону, який ви оберете, і цей діапазон є фікцією, про яку домовляються два кінці тунелю. Це не підмережа Google Cloud, вона не з'являється в списку підмереж VPC, і мережевий інтерфейс ВМ не отримує цих адрес. Тому робоче навантаження, що відповідає клієнту, надсилає пакет на адресу, яку мережа вважає немаршрутизованою.

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

Унікальна локальна адресація, як-от fd42:90::/64, — розумний вибір для цієї внутрішньої мережі. Префікс також нагадує, що дизайн за своєю природою приватний. Ніщо в пулі ULA не робить його законним джерелом у публічному інтернеті.

Дайте VPC пункт призначення і наступний крок

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

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

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

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

Пересилання потрібно ввімкнути двічі

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

Хмарній стороні потрібна ввімкнена здатність пересилання інстансу; це параметр, який дозволяє ВМ приймати трафік для адрес, якими вона не володіє, і передавати його далі. Гостьовій стороні потрібне власне пересилання IPv6, бо ядро ухвалює окреме рішення після надходження пакета. Обидва мають бути ввімкнені, перш ніж єдина відповідь перетне тунель.

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

Далі правила міжмережевого екрана мають дозволяти внутрішній діапазон джерела в обох напрямках. Google Cloud оцінює декапсульований пакет, тому правило, що охоплює лише підмережу VPC, відкидає трафік пулу після того, як тунель уже спрацював. Додайте пул як діапазон джерела у вхідне правило й перевірте, що жодна користувацька політика виходу не блокує відповідь. Неявне правило дозволу охоплює стандартний випадок, а написане вручну правило виходу — ні.

Скажіть OpenVPN, кому що належить

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

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

Тримайте вихід в інтернет поза цим дизайном

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

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