Mengapa VM GCP anda tidak boleh membalas pool IPv6 OpenVPN

Klien VPN IPv6 anda sampai ke beban kerja, beban kerja membalas ke dalam terowong, dan balasan itu tidak pernah tiba. Naluri pertama ialah menyalahkan firewall atau terowong, dan biasanya kedua-duanya tidak bersalah. Alamat yang diberikan oleh OpenVPN ialah rangkaian dalaman yang hanya wujud di dalam terowong; Google Cloud tidak tahu bahawa fd42:90::/64 sepatutnya berada di belakang satu VM tertentu sehingga anda memberitahunya.

Dua sistem berasingan perlu mempelajari fakta itu, dan hanya satu daripadanya ialah OpenVPN. VPC memerlukan laluan sebelum ia boleh menghantar apa-apa balik, dan VM mesti dibenarkan menghantar apa yang tiba. Salah pada mana-mana separuh dan gejalanya kelihatan sama.

Pool ialah rangkaian dalaman, bukan subnet

OpenVPN boleh memberikan alamat IPv6 daripada julat yang anda pilih, dan julat itu ialah rekaan yang dipersetujui kedua-dua hujung terowong. Ia bukan subnet Google Cloud, tidak muncul dalam senarai subnet VPC, dan antara muka rangkaian VM tidak memperoleh alamat tersebut. Beban kerja yang membalas klien kerana itu menghantar paket ke alamat yang dianggap tidak boleh dilalui oleh rangkaian.

Jauhkan pool daripada setiap julat yang sudah digunakan VPC. Jauhkannya juga daripada julat di belakang terowong anda yang lain. Pertindihan mengubah kegagalan penghalaan yang bersih menjadi kegagalan berselang yang hanya muncul di bawah beban.

Pengalamatan setempat unik seperti fd42:90::/64 ialah pilihan yang wajar untuk rangkaian dalaman ini. Awalan itu juga mengingatkan bahawa reka bentuk ini bersifat peribadi secara semula jadi. Tiada apa-apa pada pool ULA menjadikannya sumber yang sah di internet awam.

Berikan VPC destinasi dan hop seterusnya

Balasan memerlukan laluan VPC yang destinasinya ialah pool dan hop seterusnya ialah VM VPN. Dokumentasi laluan statik semasa merangkumi julat destinasi IPv6 dan menyenaraikan jenis hop seterusnya yang layak, jadi sahkan bentuk yang disokong untuk topologi anda dan bukannya menyalin contoh IPv4 lama.

Alamat hop seterusnya mesti alamat yang benar-benar diberikan kepada antara muka awan instans. Alamat terowong dalaman VM bukan alamat itu. Menggunakannya juga menghasilkan laluan yang dipasang dengan bersih dan tidak pernah sepadan dengan paket. Baca senarai antara muka sebelum menulis laluan.

Keutamaan laluan sama pentingnya dengan entri itu sendiri. Laluan subnet lebih khusus daripada laluan tersuai yang anda tambah, jadi pool yang dipotong daripada julat subnet sedia ada akan kalah kepada laluan subnet, tidak kira bagaimana laluan tersuai itu ditulis. Pilih pool yang berasingan, kemudian sahkan bahawa laluan itu menunjukkan instans sebagai hop seterusnya dan awalan destinasi yang betul:

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

Penghantaran mesti didayakan dua kali

Laluan menyampaikan paket kepada instans. Ia tidak membuat instans bersedia menghantar sesuatu yang tidak dialamatkan kepadanya, dan kebenaran itu wujud pada dua lapisan.

Sisi awan memerlukan keupayaan penghantaran instans didayakan; itulah tetapan yang membolehkan VM menerima trafik untuk alamat yang bukan miliknya dan menyalurkannya. Sisi tetamu memerlukan penghantaran IPv6 sendiri, kerana kernel membuat keputusan berasingan selepas paket tiba. Kedua-duanya mesti dihidupkan sebelum satu balasan melintasi terowong.

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

Selepas itu peraturan firewall mesti membenarkan julat sumber dalaman dalam kedua-dua arah. Google Cloud menilai paket yang dinyahkapsul, jadi peraturan yang hanya meliputi subnet VPC menggugurkan trafik pool selepas terowong sudah berjaya. Tambah pool sebagai julat sumber dalam peraturan masuk, dan periksa bahawa tiada dasar keluar tersuai menyekat balasan. Peraturan kebenaran tersirat meliputi kes lalai, peraturan keluar yang ditulis tangan tidak.

Beritahu OpenVPN siapa memiliki apa

OpenVPN menghantar kepada klien apabila ia tahu klien itu memiliki destinasi. Alamat klien daripada pool dikendalikan oleh arahan pelayan yang mentakrifkan pool, tetapi subnet di belakang klien ialah susunan berbeza dan memerlukan entri pemilikan yang jelas untuk klien itu.

Mencampurkan kedua-duanya menghasilkan terowong yang mana ping ke pelayan berfungsi dan tiada apa-apa di belakangnya. Tentukan kes mana yang anda bina, kemudian tulis entri yang sepadan dan bukannya menambah baris push kedua dan berharap.

Jauhkan keluar internet daripada reka bentuk ini

Akses peribadi dan akses internet ialah pelan berasingan. Pool ULA boleh mencapai beban kerja VPC melalui terowong apabila penghalaan dan penghantaran bersetuju, dan pool yang sama tiada laluan ke internet awam melalui VPC, kerana get laluan awan tidak akan menerima sumber terowong sewenang-wenangnya sebagai miliknya.

Jika klien juga memerlukan keluar internet, rancang reka bentuk pengalamatan dan penghalaan yang disokong untuknya, kekalkan ia bebas daripada pool peribadi, dan uji kedua-dua laluan secara berasingan. Satu laluan yang berfungsi tidak memberitahu apa-apa tentang yang lain, dan reka bentuk yang mencampurkan kedua-duanya gagal dengan cara yang kelihatan seperti terowong rosak.