GCP VM'iniz OpenVPN IPv6 havuzuna neden yanıt veremiyor

IPv6 VPN istemciniz iş yüküne ulaşıyor, iş yükü tünelin içine yanıt veriyor ama yanıt hiç gelmiyor. İlk tepki güvenlik duvarını veya tüneli suçlamaktır ve genellikle ikisi de suçlu değildir. OpenVPN tarafından dağıtılan adres, yalnızca tünelin içinde var olan bir iç ağdır; Google Cloud, siz söyleyene kadar fd42:90::/64'ün belirli bir VM'in arkasında olması gerektiğini bilmez.

Bu gerçeği iki ayrı sistemin öğrenmesi gerekir ve bunlardan yalnızca biri OpenVPN'dir. VPC'nin bir şeyi geri gönderebilmesi için önce rotaya ihtiyacı vardır ve VM'in geleni iletmesine izin verilmelidir. İki yarıdan herhangi birinde hata yaparsanız belirti aynı görünür.

Havuz bir iç ağdır, alt ağ değildir

OpenVPN, seçtiğiniz aralıktan IPv6 adresleri dağıtabilir ve bu aralık tünelin iki ucunun üzerinde anlaştığı bir kurgudur. Google Cloud alt ağı değildir, VPC alt ağ listesinde görünmez ve VM'in ağ arayüzü bu adresleri almaz. Bu nedenle istemciye yanıt veren iş yükü, ağın yönlendirilemez saydığı bir adrese paket gönderir.

Havuzu VPC'nin zaten kullandığı her aralığın dışında tutun. Diğer tünellerinizin arkasındaki aralıkların dışında da tutun. Çakışma, temiz bir yönlendirme hatasını yalnızca yük altında görünen aralıklı bir hataya dönüştürür.

fd42:90::/64 gibi benzersiz yerel adresleme bu iç ağ için makul bir seçimdir. Önek ayrıca tasarımın doğası gereği özel olduğunu hatırlatır. Bir ULA havuzundaki hiçbir şey onu genel internette meşru bir kaynak yapmaz.

VPC'ye bir hedef ve bir sonraki atlama verin

Yanıt için hedefi havuz, sonraki atlaması VPN VM'i olan bir VPC rotası gerekir. Mevcut statik rota belgeleri IPv6 hedef aralıklarını kapsar ve hangi sonraki atlama türlerinin uygun olduğunu listeler, bu yüzden eski bir IPv4 örneğini kopyalamak yerine topolojiniz için desteklenen biçimi doğrulayın.

Sonraki atlama adresi gerçekten örneğin bulut arayüzüne atanmış bir adres olmalıdır. VM'in iç tünel adresi o adres değildir. Yine de kullanmak, temiz kurulan ve hiçbir paketle eşleşmeyen bir rota üretir. Rotayı yazmadan önce arayüz listesini okuyun.

Rota önceliği, kaydın kendisi kadar önemlidir. Alt ağ rotaları, eklediğiniz özel rotalardan daha belirlidir; bu yüzden mevcut bir alt ağ aralığından kesilen havuz, özel rota nasıl yazılırsa yazılsın alt ağ rotasına yenilir. Ayrı bir havuz seçin, ardından rotanın örneği sonraki atlama ve doğru hedef öneki olarak gösterdiğini doğrulayın:

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

İletme iki kez etkinleştirilmelidir

Bir rota paketi örneğe teslim eder. Bu, örneği kendisine adreslenmemiş bir şeyi iletmeye istekli hale getirmez ve bu izin iki katmanda bulunur.

Bulut tarafında örneğin iletme yeteneğinin etkin olması gerekir; bu, bir VM'in sahip olmadığı adresler için trafik almasına ve iletmesine izin veren ayardır. Konuk tarafında kendi IPv6 iletmesi gerekir, çünkü çekirdek paket geldikten sonra ayrı bir karar verir. Tek bir yanıt tüneli geçmeden önce ikisi de açık olmalıdır.

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

Ardından güvenlik duvarı kuralları iç kaynak aralığına her iki yönde izin vermelidir. Google Cloud kapsülü çözülmüş paketi değerlendirir, bu nedenle yalnızca VPC alt ağını kapsayan bir kural, tünel zaten başarılı olduktan sonra havuz trafiğini düşürür. Havuzu giriş kuralına kaynak aralığı olarak ekleyin ve özel bir çıkış ilkesinin yanıtı engellemediğini kontrol edin. Örtük izin kuralı varsayılan durumu kapsar, elle yazılmış bir çıkış kuralı kapsamaz.

OpenVPN'e kimin neye sahip olduğunu söyleyin

OpenVPN, o istemcinin hedefe sahip olduğunu bildiğinde istemciye iletir. Havuzdan gelen istemci adresleri havuzu tanımlayan sunucu yönergesi tarafından işlenir, ancak bir istemcinin arkasındaki alt ağ farklı bir düzenlemedir ve o istemci için açık bir sahiplik kaydı gerektirir.

İkisini karıştırmak, sunucuya pinglerin çalıştığı ama arkasında hiçbir şeyin çalışmadığı bir tünel üretir. Hangi durumu kurduğunuza karar verin, ardından ikinci bir push satırı ekleyip ummak yerine eşleşen kaydı yazın.

İnternet çıkışını bu tasarımın dışında tutun

Özel erişim ve internet erişimi ayrı planlardır. ULA havuzu, yönlendirme ve iletme anlaştığında tünel üzerinden VPC iş yüklerine ulaşabilir ve aynı havuzun VPC üzerinden genel internete hiçbir yolu yoktur, çünkü bulut ağ geçidi rastgele bir tünel kaynağını kendisi olarak kabul etmez.

İstemciler internet çıkışına da ihtiyaç duyuyorsa, bunun için desteklenen bir adresleme ve yönlendirme tasarımı planlayın, onu özel havuzdan bağımsız tutun ve iki yolu ayrı ayrı test edin. Çalışan bir yol diğeri hakkında hiçbir şey söylemez ve ikisini karıştıran bir tasarım bozuk tünel gibi görünen bir şekilde başarısız olur.