GCP VM-iniz OpenVPN IPv6 hovuzuna niyə cavab verə bilmir

IPv6 VPN müştəriniz iş yükünə çatır, iş yükü tunelin içinə cavab verir və cavab heç vaxt gəlib çatmır. İnsanın ilk instinkti firewall-u və ya tuneli günahlandırmaqdır və adətən heç biri günahkar olmur. OpenVPN tərəfindən verilən ünvan yalnız tunelin içində mövcud olan daxili şəbəkədir; Google Cloud fd42:90::/64-ün müəyyən bir VM-in arxasında olması lazım olduğunu siz ona deyənə qədər bilmir.

Bu faktı iki ayrı sistem öyrənməlidir və onlardan yalnız biri OpenVPN-dir. VPC hər hansı bir şeyi geri göndərməzdən əvvəl marşruta ehtiyac duyur, VM isə gələnləri yönləndirməyə icazəli olmalıdır. Hər iki yarıdan birini səhv etsəniz, simptom eyni görünür.

Hovuz daxili şəbəkədir, alt şəbəkə deyil

OpenVPN seçdiyiniz diapazondan IPv6 ünvanları verə bilər və bu diapazon iki tunel ucunun razılaşdığı bir uydurmadır. O, Google Cloud alt şəbəkəsi deyil, VPC alt şəbəkə siyahısında görünmür və VM-in şəbəkə interfeysi bu ünvanları almır. Buna görə müştəriyə cavab verən iş yükü paketi şəbəkənin marşrutsuz saydığı ünvana göndərir.

Hovuzu VPC-nin artıq istifadə etdiyi hər diapazondan kənarda saxlayın. Digər tunellərinizin arxasındakı diapazonlardan da kənarda saxlayın. Üst-üstə düşmə təmiz marşrut xətasını yalnız yük altında görünən fasiləli bir xətaya çevirir.

fd42:90::/64 kimi unikal lokal ünvanlama bu daxili şəbəkə üçün ağlabatan seçimdir. Prefiks həm də dizaynın təbiətcə şəxsi olduğunu xatırladır. ULA hovuzunu heç nə ictimai internetdə qanuni mənbə etmir.

VPC-yə təyinat və növbəti hop verin

Cavab üçün təyinatı hovuz, növbəti hopu isə VPN VM olan VPC marşrutu lazımdır. Mövcud statik marşrut sənədləri IPv6 təyinat diapazonlarını əhatə edir və hansı növbəti hop növlərinin uyğun olduğunu sadalayır, ona görə köhnə IPv4 nümunəsini kopyalamaq əvəzinə topologiyanız üçün dəstəklənən formanı yoxlayın.

Növbəti hop ünvanı həqiqətən instansın bulud interfeysinə təyin edilmiş olmalıdır. VM-in daxili tunel ünvanı o ünvan deyil. Yenə də istifadə etmək təmiz quraşdırılan və heç vaxt heç bir paketə uyğun gəlməyən marşrut yaradır. Marşrutu yazmadan əvvəl interfeys siyahısını oxuyun.

Marşrut prioriteti girişin özü qədər vacibdir. Alt şəbəkə marşrutları əlavə etdiyiniz fərdi marşrutlardan daha dəqiqdir, ona görə mövcud alt şəbəkə diapazonundan kəsilmiş hovuz, fərdi marşrutun necə yazılmasından asılı olmayaraq, alt şəbəkə marşrutuna uduzacaq. Fərqli bir hovuz seçin, sonra marşrutun instansı növbəti hop və düzgün təyinat prefiksini göstərdiyini təsdiqləyin:

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

Yönləndirmə iki dəfə aktivləşdirilməlidir

Marşrut paketi instansa çatdırır. Bu, instansı ona ünvanlanmayan bir şeyi yönləndirməyə hazır etmir və bu icazə iki qatda mövcuddur.

Bulud tərəfində instans yönləndirmə qabiliyyəti aktiv olmalıdır; bu, VM-in sahibi olmadığı ünvanlar üçün trafiki qəbul edib ötürməsinə imkan verən parametrdir. Qonaq tərəfində öz IPv6 yönləndirməsi olmalıdır, çünki nüvə paket gəldikdən sonra ayrı qərar verir. Tək bir cavab tuneldən keçməzdən əvvəl hər ikisi aktiv olmalıdır.

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

Sonra firewall qaydaları daxili mənbə diapazonunu hər iki istiqamətdə qəbul etməlidir. Google Cloud dekapsulyasiya olunmuş paketi qiymətləndirir, ona görə yalnız VPC alt şəbəkəsini əhatə edən qayda tunel artıq uğurlu olduqdan sonra hovuz trafikini atır. Hovuzu giriş qaydasına mənbə diapazonu kimi əlavə edin və heç bir fərdi çıxış siyasətinin cavabı bloklamadığını yoxlayın. Gizli icazə qaydası standart halı əhatə edir, əl ilə yazılmış çıxış qaydası isə etmir.

OpenVPN-ə kimin nəyə sahib olduğunu deyin

OpenVPN müştərinin təyinatın sahibi olduğunu bildikdə ona yönləndirir. Hovuzdan gələn müştəri ünvanları hovuzu təyin edən server direktivi ilə idarə olunur, lakin müştərinin arxasındakı alt şəbəkə fərqli bir quruluşdur və həmin müştəri üçün açıq sahiblik girişi tələb edir.

İkisini qarışdırmaq serverə ping-lərin işlədiyi, arxasındakı heç nəyin işləmədiyi tunel yaradır. Hansı halı qurduğunuza qərar verin, sonra ikinci push sətri əlavə edib ümid etmək əvəzinə uyğun girişi yazın.

İnternet çıxışını bu dizayndan kənarda saxlayın

Şəxsi giriş və internet girişi ayrı planlardır. ULA hovuzu marşrut və yönləndirmə razılaşdıqdan sonra tunel üzərindən VPC iş yüklərinə çata bilər və həmin hovuzun VPC vasitəsilə ictimai internetə heç bir yolu yoxdur, çünki bulud şlüzü ixtiyari tunel mənbəyini öz mənbəyi kimi qəbul etməyəcək.

Müştərilər də internet çıxışına ehtiyac duyursa, bunun üçün dəstəklənən ünvanlama və marşrut dizaynı planlaşdırın, onu şəxsi hovuzdan asılı olmayaraq saxlayın və iki yolu ayrıca test edin. İşləyən bir yol digəri haqqında heç nə demir və ikisini qarışdıran dizayn pozulmuş tunel kimi görünən şəkildə uğursuz olur.