GCP VM'ine Cloud VPN: NAT IP'yi değil, iç IP'yi kullanın

Şirket içi bir ağ Cloud VPN üzerinden bir VPC'ye ulaştığında, bir Compute Engine hizmeti için hedef genellikle VM'nin iç adresidir. Dış IPv4 adresi, aynı özel rotaya koyabileceğiniz ikinci bir adres değildir. Bu alandaki karışıklığın çoğu, üç işi olan üç adresin birbirinin yerine kullanılabilir sanılmasından gelir; bu yüzden belirli bir paketin hangisini kullandığını adlandırarak başlayın.

Üç adres, üç iş

Herhangi birinde hata ayıklamaya başlamadan önce üçünü de adlandırın, çünkü yanıt bir sonra inceleyeceğiniz nesneyi değiştirir.

Birincisi tünele aittir. İkincisi rota ve güvenlik duvarı tasarımınıza aittir. Üçüncüsü gelen internet erişimine aittir ve eşlenir, eklenmez. Bunlardan biri için çalışan bir tasarım diğer ikisi hakkında hiçbir şey söylemez.

Dış adres neden ikinci bir arayüz değil

Adresleme kılavuzu, Compute Engine'de iç ve dış erişilebilirliğin nasıl farklılaştığı konusunda yetkili kaynaktır. Compute Engine dış IPv4 adresi, örneğin tek iç NIC'si üzerinde bire bir eşlemedir; bu yüzden konuk o NIC üzerinde asla ikinci bir arayüz veya ikinci bir adres görmez. VM'nin içeriden bildirdiği şey hâlâ tek bir birincil iç adrestir.

Bu nedenle özel bir istemcinin tünel üzerinden 10.24.1.7 adresine yönlendirme yapması ile VM'nin dış adresini hedefleyen bir istemci farklı yollardadır. Genel adres için bir güvenlik duvarı kuralı açmak, tünel trafiğini taşıması gereken VPC rotasında hiçbir şeyi değiştirmez ve konuktaki bir rotayı düzenlemek platformun eşlemesini hareket ettirmez. Rotanızın adlandırdığı adresi seçin, sonra yalnızca onu yöneten nesneleri inceleyin. Bu disiplin, bu sorun giderme yolundan tahminlerin çoğunu çıkarır.

Yolu gcloud ile yürüyün

Örnekten başlayın ve iki adresi de aynı nesneden okuyun, böylece belgelerinizin hangisinden söz ettiğini bilirsiniz:

gcloud compute instances describe app-1 --zone=europe-west1-b \
  --format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"

Ardından yolun gerçekten bağlı olduğu yönlendirmeyi ve izni doğrulayın:

gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1

Tünelin duyurduğu ve öğrendiği aralıkları okuyun, iş yükü alt ağının VPC rotasını ve şirket içi kaynağa izin veren güvenlik duvarı kuralını. Konuktaki bir dinleyici anlamlı olmadan önce bu üçü uyuşmalıdır.

Ardından konuğu kontrol edin: hizmet iç adreste mi dinliyor ve dönüş yolu yeniden VPC üzerinden mi geçiyor? Yalnızca genel bir adrese bağlı bir dinleyici, bulut tarafındaki her nesne doğru olsa bile bu testte başarısız olur.

Genel bir önek başka bir sorudur

Yukarıdakilerin hiçbiri, bir VPN içinde taşınan her adresin RFC1918 olması gerektiği anlamına gelmez. Uzak bir ağ, platform yönlendirmeyi destekliyorsa ve operatör adres yetkisine sahipse, genel uzaydan meşru şekilde numaralandırılabilir. Bu normal bir tasarım tercihidir.

Bu, sıradan bir dış NAT adresini başka bir iç alt ağ adresi gibi ele almakla aynı şey değildir. Biri yönlendirdiğiniz bir önektir; diğeri platformun gelen erişime uyguladığı bir eşlemedir.

Dış IPv6 ve özel olarak tasarlanmış adres düzenlemelerinin kendi anlambilimi vardır. Planınız bunlardan birine bağlıysa, IPv4 durumundan genelleme yapmak yerine o özelliğin platform belgelerini okuyun. IPv4 eşlemesi yaygın durumdur, tek durum değildir ve her istisnanın kendi kuralları vardır.

Çakışan aralıklar başka bir sorundur

Çakışan özel aralıklar, insanların genel adrese başvurmasının gerçek nedenidir ve bu yanlış koldur. Hedefi VM'nin NAT adresine değiştirmek çakışmayı çözmez; paketin hangi adres için olduğunu iddia ettiğini değiştirir, dönüş yolunun nasıl çalıştığını tanımlamadan.

Çakışmayı bilinçli olarak çözün: yeniden numaralandırın, desteklenen bir çeviri tasarımı kullanın veya öneklerin çakışmadığı bir ağ üzerinden yönlendirin. Bunların her biri sahibi olan bir tasarımdır. NAT adresi bir tasarım değildir.

İki alanı ayrı ayrı belgeleyin

Tünel eşini ve iş yükü hedefini iki ayrı runbook alanı olarak kaydedin; her biri kendisini destekleyen rota ve güvenlik duvarı kuralıyla birlikte. Ayağa kalkan bir IPsec tüneli yalnızca tarafların anlaştığını söyler; iş yükünün hangi adreste erişilebilir olduğunu ve özel rotasının eksiksiz olup olmadığını söylemez.

Karşı tarafta gerçek bir istemciyle doğrulayın: adı çözün, iç adresi döndürdüğünü onaylayın, bağlanın ve dönüş trafiğini kontrol edin. Compute Engine IP adresleri belgeleri yukarıda kullanılan iç-dış ayrımının referansıdır.