Чаму ваша ВМ у 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, бо хмарны шлюз не прыме адвольную крыніцу тунеля як уласную.

Калі кліентам таксама патрэбны выхад у інтэрнэт, заплануйце для гэтага падтрыманы дызайн адрасацыі і маршрутызацыі, трымайце яго незалежным ад прыватнага пула і тэстуйце два шляхі асобна. Адзін працоўны шлях нічога не кажа пра другі, а дызайн, які змешвае іх, адмаўляе так, што выглядае як зламаны тунель.