Mengapa VM GCP Anda tidak bisa membalas pool IPv6 OpenVPN

Klien VPN IPv6 Anda mencapai beban kerja, beban kerja membalas ke dalam terowongan, dan balasannya tidak pernah tiba. Naluri pertama adalah menyalahkan firewall atau terowongan, dan biasanya keduanya tidak bersalah. Alamat yang diberikan oleh OpenVPN adalah jaringan dalam yang hanya ada di dalam terowongan; Google Cloud tidak tahu bahwa fd42:90::/64 seharusnya berada di belakang satu VM tertentu sampai Anda memberitahunya.

Dua sistem terpisah harus mempelajari fakta itu, dan hanya satu di antaranya adalah OpenVPN. VPC memerlukan rute sebelum dapat mengirim apa pun kembali, dan VM harus diizinkan meneruskan apa yang datang. Salah di salah satu bagian dan gejalanya tampak sama.

Pool adalah jaringan dalam, bukan subnet

OpenVPN dapat memberikan alamat IPv6 dari rentang yang Anda pilih, dan rentang itu adalah fiksi yang disepakati kedua ujung terowongan. Itu bukan subnet Google Cloud, tidak muncul di daftar subnet VPC, dan antarmuka jaringan VM tidak memperoleh alamat tersebut. Beban kerja yang membalas klien karena itu mengirim paket ke alamat yang dianggap tidak dapat dirutekan oleh jaringan.

Jauhkan pool dari setiap rentang yang sudah dipakai VPC. Jauhkan juga dari rentang di belakang terowongan Anda yang lain. Tumpang tindih mengubah kegagalan perutean yang bersih menjadi intermiten yang hanya muncul di bawah beban.

Pengalamatan lokal unik seperti fd42:90::/64 adalah pilihan yang wajar untuk jaringan dalam ini. Prefiks itu juga mengingatkan bahwa desainnya bersifat privat secara bawaan. Tidak ada yang membuat pool ULA menjadi sumber yang sah di internet publik.

Beri VPC tujuan dan hop berikutnya

Balasan memerlukan rute VPC yang tujuannya adalah pool dan hop berikutnya adalah VM VPN. Dokumentasi rute statis saat ini mencakup rentang tujuan IPv6 dan mencantumkan jenis hop berikutnya yang memenuhi syarat, jadi verifikasi bentuk yang didukung untuk topologi Anda alih-alih menyalin contoh IPv4 lama.

Alamat hop berikutnya harus alamat yang benar-benar ditetapkan ke antarmuka cloud instans. Alamat terowongan dalam VM bukan alamat itu. Tetap memakainya menghasilkan rute yang terpasang bersih dan tidak pernah cocok dengan paket. Baca daftar antarmuka sebelum menulis rute.

Prioritas rute sama pentingnya dengan entri itu sendiri. Rute subnet lebih spesifik daripada rute kustom yang Anda tambahkan, jadi pool yang dipotong dari rentang subnet yang ada akan kalah dari rute subnet, tidak peduli bagaimana rute kustom itu ditulis. Pilih pool yang berbeda, lalu pastikan rute menampilkan instans sebagai hop berikutnya dan prefiks tujuan yang benar:

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

Penerusan harus diaktifkan dua kali

Rute mengantarkan paket ke instans. Rute tidak membuat instans bersedia meneruskan sesuatu yang tidak dialamatkan kepadanya, dan izin itu ada di dua lapisan.

Sisi cloud memerlukan kemampuan penerusan instans diaktifkan, yaitu pengaturan yang memungkinkan VM menerima lalu lintas untuk alamat yang bukan miliknya dan meneruskannya. Sisi tamu memerlukan penerusan IPv6 sendiri, karena kernel mengambil keputusan terpisah setelah paket tiba. Keduanya harus menyala sebelum satu balasan pun melintasi terowongan.

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

Aturan firewall kemudian harus mengizinkan rentang sumber dalam di kedua arah. Google Cloud mengevaluasi paket yang didekapsulasi, jadi aturan yang hanya mencakup subnet VPC menjatuhkan lalu lintas pool setelah terowongan sudah berhasil. Tambahkan pool sebagai rentang sumber pada aturan masuk, dan periksa bahwa tidak ada kebijakan keluar kustom yang memblokir balasan. Aturan izinkan implisit mencakup kasus default, aturan keluar yang ditulis tangan tidak.

Beri tahu OpenVPN siapa memiliki apa

OpenVPN meneruskan ke klien ketika ia tahu klien itu memiliki tujuan. Alamat klien dari pool ditangani oleh direktif server yang mendefinisikan pool, tetapi subnet di belakang klien adalah susunan berbeda dan memerlukan entri kepemilikan eksplisit untuk klien itu.

Mencampur keduanya menghasilkan terowongan tempat ping ke server berfungsi dan tidak ada apa pun di belakangnya. Putuskan kasus mana yang Anda bangun, lalu tulis entri yang sesuai alih-alih menambahkan baris push kedua dan berharap.

Jauhkan egress internet dari desain ini

Akses privat dan akses internet adalah rencana terpisah. Pool ULA dapat mencapai beban kerja VPC melalui terowongan begitu perutean dan penerusan sepakat, dan pool yang sama tidak punya jalur ke internet publik melalui VPC, karena gateway cloud tidak akan menerima sumber terowongan sembarang sebagai miliknya.

Jika klien juga memerlukan egress internet, rencanakan desain pengalamatan dan perutean yang didukung untuk itu, jaga tetap independen dari pool privat, dan uji kedua jalur secara terpisah. Satu jalur yang berfungsi tidak memberi tahu apa pun tentang yang lain, dan desain yang mencampur keduanya gagal dengan cara yang tampak seperti terowongan rusak.