Google PCNE: Google'a Özel Bağlantı ve Yönetilen Hizmetler — Çalışma kılavuzu

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Şunun bir parçası: Google Professional Cloud Network Engineer — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Google sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Genel Bakış

Google ve yönetilen hizmetlere özel bağlantı, iş yüklerinin genel IP’ler kullanmadan Google API’leri, Google tarafından yönetilen üretici ağları ve üçüncü taraf hizmetlerle iletişim kurmasını sağlayan kalıpları kapsar. Amaçlar, trafiği özel yollarda tutarak veri sızdırma riskini azaltmak, uyumluluğu basitleştirmek ve öngörülebilirliği artırmaktır. Temel yapı taşları arasında Private Google Access (ve kısıtlanmış uç noktalar), Private Services Access (Google tarafından yönetilen hizmetlere özel IP’ler için), Private Service Connect (üretici-tüketici özel hizmet yayınlama ve tüketimi için, Google API’leri dahil), VPC Service Controls (veri perimetresi oluşturma), Cloud NAT (genel internete özel giden trafik) ve belirleyici uç nokta seçimi için DNS eşlemesi bulunur.

Tasarım başarısı üç karara bağlıdır:

Hangi özel erişim mekanizmasının hizmet ve güvenlik modeline uyduğu (Google API’leri için PGA vs PSC, yönetilen veya iş ortağı hizmetleri için PSA vs PSC).
DNS’in, desteklenmeyen hizmetleri bozmadan hizmet adlarını özel hedeflere nasıl çözümlemesi gerektiği.
Bir arıza veya değişiklik durumunda trafiğin uçtan uca özel kalması için yönlendirme ve perimetre politikasının nasıl etkileşime girdiği.

Hata modları genellikle rota seçimi, DNS sırası, uç noktaların bölgesel kapsamı veya çağrıları sessizce reddeden perimetre kurallarından kaynaklanır. Her katmanı doğrulayın: ad çözümleme, rota, güvenlik duvarı, uç nokta sağlığı ve hizmet politikası.

Private Google Access, kısıtlanmış uç noktalar ve uç nokta seçimi

Private Google Access (PGA), harici IP’leri olmayan VM’lerin ve GKE düğümlerinin, Cloud NAT üzerinden değil, VPC’nin varsayılan internet ağ geçidi üzerinden Google anycast VIP’lerini kullanarak Google API’lerine ve hizmetlerine ulaşmasını sağlar. Alt ağ başına etkinleştirilir.

Uç Noktalar:
- private.googleapis.com (199.36.153.8/30): tüm Google API’leri yüzeyi.
- restricted.googleapis.com (199.36.153.4/30): VPC Service Controls ile uyumlu API’lerin bir alt kümesi. Hizmet perimetrelerini zorunlu kıldığınızda bunu kullanın.
DNS eşleme yaklaşımları:
- Varsayılan genel adları koruyun ve istemcilerin genel DNS’e erişmesine izin verin. Bu, Cloud NAT üzerinden giden trafiğe izin verirseniz işe yarar, ancak veri sızdırma kontrollerini zayıflatır.
- Her hizmet için özel çözümlemeyi zorlamak amacıyla, googleapis.com için bir Cloud DNS özel bölgesindeki belirli API ana bilgisayar adlarını, restricted.googleapis.com’a (veya private.googleapis.com’a) yönlendiren CNAME’lerle geçersiz kılın. Örnek: googleapis.com adında bir özel bölge oluşturun ve storage.googleapis.com CNAME restricted.googleapis.com kaydını ekleyin.
Yönlendirme ile ilgili dikkat edilmesi gerekenler:
- PGA, varsayılan internet ağ geçidine bir rota gerektirir. Eğer 0.0.0.0/0 trafiğini üçüncü taraf bir NGFW’ye gönderiyorsanız, Google API VIP’lerinin varsayılan internet ağ geçidini kullanması için açık ana bilgisayar rotaları ekleyin:

undefined

Hata modu: Bu ana bilgisayar rotaları eksikse, 0.0.0.0/0 sonraki atlama (next-hop) hedefi bir güvenlik duvarı örneği olduğunda, harici IP’leri olmayan örnekler API’lere ulaşamaz.
Alt ağ yapılandırması:

undefined

Artıları ve eksileri:

restricted.googleapis.com veri sızdırma riskini azaltır ancak bazı API’ler kullanılamaz.
PGA trafiği Cloud NAT’ı atlar, bu nedenle NAT günlüklerinde görünmez. Alt ağda VPC Akış Günlüklerini (VPC Flow Logs) kullanın.

Şirket içi (on-prem) istemciler için, Google API’lerine özel erişimi, VPC’deki sonraki atlama (next hop) hedefi varsayılan internet ağ geçidi olacak şekilde Cloud VPN/Interconnect üzerinden şirket içine 199.36.153.4/30 ve/veya 199.36.153.8/30 adreslerini anons ederek veya PSC uç noktalarını (aşağıya bakın) kullanıma sunup şirket içi DNS’i bu uç noktalara eşleyerek sağlayabilirsiniz.

Private Services Access ve Private Service Connect

Private Services Access (PSA), Cloud SQL (özel IP) ve Memorystore gibi hizmetleri barındıran, Google tarafından yönetilen üretici ağlarına özel IP bağlantısı sağlar. VPC’nizde Google’ın kullanması için bir RFC1918 aralığı ayırır ve hizmet üreticisi ağıyla bir peering bağlantısı kurarsınız.

Kurulum modeli:
- VPC peering için bir adres aralığı ayırın: gcloud compute addresses create google-managed-services-range
  –global –purpose=VPC_PEERING –prefix-length=24 –network=VPC
- Özel bağlantıyı kurun: gcloud services vpc-peerings connect
  –service=servicenetworking.googleapis.com –network=VPC
  –ranges=google-managed-services-range
- Yönetilen hizmeti özel IP ile sağlayın.
Operasyonel notlar:
- Aralık, tüm örnekler için yeterince büyük olmalı ve mevcut aralıklarla çakışmamalıdır.
- Peering geçişli (transitive) değildir; trafik, peer yapılan VPC’den kaynaklanmalıdır (şirket içi (on-prem) ağlar, yönlendirme izin veriyorsa VPC üzerinden ulaşabilir).
- Aralığı daha sonra değiştirmek veya küçültmek kesintiye neden olur; kapasiteyi iyi planlayın.

Private Service Connect (PSC), özel bağlantıyı şu hedeflere genişletir:

Google API’leri (tüketici, bir alt ağda özel IP’lere sahip uç noktalar oluşturur ve DNS, API adlarını bu IP’lere eşler).
Hizmet ekleri (service attachments) aracılığıyla yayınlanan iş ortağı ve SaaS hizmetleri.
Hizmet ekleri aracılığıyla diğer projelere veya kuruluşlara özel olarak yayınlanan kendi hizmetleriniz.

Üretici-tüketici modeli:

Üretici, bir bölgede dahili bir yük dengeleyici (internal load balancer) tarafından desteklenen bir hizmet eki (service attachment) yayınlar. Üretici, tüketici projesi/kuruluşu için izin listeleri (allowlists) zorunlu kılabilir ve bağlantı kotaları belirleyebilir.
Tüketici, aynı bölgede üreticinin hizmet ekini hedefleyen bir PSC uç noktası (yönlendirme kuralı - forwarding rule) oluşturur. Uç nokta, seçilen alt ağdan bir IP alır.

Tasarım kısıtlamaları ve ödünleşimler:

PSC bölgeseldir; tüketicilere yakın olacak şekilde bölge başına dağıtım yapın. Yakındaki istemcileri yönlendirmek ve yük devretme (failover) sağlamak için DNS ilkelerini veya ağırlıklı kayıtları (weighted records) kullanın.
PSC üzerinden geçişlilik (transitivity) yoktur; tüketiciler bir uç nokta aracılığıyla hizmetleri zincirleyemez.
Kaynak IP, PSC boyunca uçtan uca korunmaz; üretici tarafı kontrollerini bunu göz önünde bulundurarak tasarlayın (örneğin, kimlik veya uygulama düzeyinde yetkilendirmeye dayanın).

Yaygın hata modları:

Üretici ILB sağlık kontrollerinin başarısız olması, PSC bağlantılarının reddedilmesine neden olur.
Tüketici uç noktasının, hizmet ekinden farklı bir bölgede oluşturulması.
Üreticinin reddetme ilkesi (deny policy) veya eksik proje izin listesinin (allowlist) bağlantıları engellemesi.
DNS’in uç nokta IP’sini göstermemesi veya çakışan özel bölgelerin (private zones) yanlış hedefe çözümlenmesi.

VPC Service Controls, çevreler, giriş/çıkış ve DNS eşlemesi

VPC Service Controls (VPC-SC), veri sızmasını azaltmak için Google tarafından yönetilen kaynakların etrafında hizmet çevreleri (service perimeters) tanımlar. Bir çevre içinde, korunan hizmetlere yönelik istekler kapsam dahilindeki projelerden kaynaklanmalı ve yapılandırılmış tüm erişim seviyelerini karşılamalıdır.

Çevreler:
- Standart çevreler, veri barındıran projeleri (örneğin, BigQuery, Cloud Storage) korur.
- Çevre köprüleri (Perimeter bridges), normalde yalıtılmış olan çevreler arasında sınırlı etkileşime izin verir.
- Giriş kuralları (Ingress rules), çevrenin dışından belirli erişimlere izin verir (örneğin, CI/CD veya izleme projelerinden).
- Çıkış kuralları (Egress rules), Google Cloud içindeki hangi harici hizmetlerin veya projelerin çağrılabileceğini kısıtlar.
Uç nokta seçimi:
- API çağrılarını VPC-SC uyumlu hizmetlerle sınırlamak ve çevreye duyarlı olmayan genel uç noktalara yanlışlıkla çağrı yapılmasını önlemek için restricted.googleapis.com kullanın.
- Google API’leri için PSC, trafiği özel IP’lerde tutarak ve bölgesel yakınlığı (regional affinity) etkinleştirerek daha güçlü kontrol sunar, ancak yetkilendirme için yine de çevre yapılandırması gerektirir.
DNS ve adlandırma:
- Dahili istemcilerin API adlarını özel hedeflere çözümlemesi için Cloud DNS özel bölgeleri (private zones) ile bölünmüş ufuklu DNS (split-horizon DNS) uygulayın.
- Genel kalması gereken hizmetleri bozabilecek olan tüm googleapis.com için joker karakter (wildcard) kullanmak yerine, restricted.googleapis.com’a hizmet başına kayıtlar veya CNAME’ler kullanmayı tercih edin.
- PSC için, her bir uç noktanın IP’sini gösteren A kayıtları yayınlayın. Ortamlar arası yanlışlıkla tüketimi önlemek için her ortam için ayrı bölgeler (zone) kullanın.

Tuzaklar:

Genel googleapis.com’a ulaşmak için Cloud NAT kullanmak, çevre kuralları çıkışı (egress) açıkça kısıtlamadığı sürece VPC-SC amacını atlayabilir; NAT’ı kısıtlanmış DNS (restricted DNS) veya PSC ile eşleştirin.
Bazı API’lerin birden çok ana bilgisayar adı (hostname) vardır (örneğin, JSON ve XML uç noktaları); DNS eşlemenizin, istemcilerinizin kullandığı tüm adları kapsadığından emin olun.
Çevre yapılandırma hataları erişimi engeller (fails closed); reddedilmeleri tespit etmek için Access Transparency ve VPC-SC günlüklerini izleyin.

Giden trafik desenleri, hibrit erişim ve sorun giderme

Özel iş yükleri için giden trafik desenleri:

Yalnızca Google API’leri: PGA’yı etkinleştirin ve DNS’i restricted.googleapis.com’a yönlendirin veya Google API’leri için PSC dağıtıp DNS’i uç nokta IP’lerine yönlendirin.
İnternet ve SaaS: Harici IP’si olmayan sanal makineler için Cloud NAT kullanın. NAT’ı en yüksek eş zamanlı bağlantı ve port sayısına göre boyutlandırın; port tükenmesini izleyin.
Üçüncü taraf bir NGFW ile karma kullanım: NGFW’yi varsayılan olarak tutun, ancak PGA’nın güvenlik duvarını atlamasını sağlamak için Google API anycast VIP’lerine özel ana makine rotaları ekleyin. Google dışı hedefler için, politikaya göre NGFW’ye veya Cloud NAT’a gönderin.

Hibrit istemciler (şirket içi veya diğer bulutlar):

Google API’lerini özel olarak kullanmak için:
- Seçenek A: VPC’deki bir sonraki atlama (next hop) varsayılan internet ağ geçidi olacak şekilde, Cloud Router’dan şirket içine 199.36.153.4/30 ve/veya 199.36.153.8/30 anons ederek şirket içi için Private Google Access kullanın; şirket içi DNS’i gerektiği gibi restricted/private.googleapis.com’a yönlendirin.
- Seçenek B: VPC’nizde Google API’leri için PSC uç noktaları kullanın; uç nokta IP’lerine yönlendirme yaparak ve şirket içi DNS’i buna göre yönlendirerek bunları Cloud VPN/Interconnect üzerinden kullanıma açın.
Özel IP’li Google tarafından yönetilen hizmetlere (PSA aracılığıyla) ulaşmak için, VPC’ye bağlantı kurun (Cloud VPN/Interconnect), RFC1918 aralıklarının çakışmadığından emin olun, rotaları yayın ve güvenlik duvarı kurallarına izin verin.

Sorun giderme ve doğrulama:

DNS: Bir istemciden API ana makine adına dig veya nslookup komutunu çalıştırın ve hedeflenen özel adrese (PSC uç nokta IP’si) veya restricted/private anycast VIP’lerine çözümlendiğini doğrulayın. VPC’deki Cloud DNS politika sırasını ve özel bölgeleri (private zones) kontrol edin.
Yönlendirme: gcloud compute routes list komutunu çalıştırın ve en spesifik rotanın hedeflenen bir sonraki atlama (PGA VIP’leri için varsayılan internet ağ geçidi, PSC için dahili) ile eşleştiğini onaylayın.
Güvenlik Duvarı: Giden trafik kurallarının hedef IP’lere TCP 443 trafiğine izin verdiğini doğrulayın. PSC arkasındaki yük dengeli üreticiler için, sağlık kontrolü kaynak aralıklarına izin verildiğini doğrulayın.
PGA: Alt ağ ayarının etkinleştirildiğini ve özel bir varsayılan rota varsa 199.36.153.4/30 ve/veya 199.36.153.8/30 için ana makine rotalarının mevcut olduğunu onaylayın.
PSA: servicenetworking eşlemesinin (peering) ACTIVE durumda olduğunu ve ayrılan aralığın doğru ve başka bir yerde kullanılmadığını onaylamak için gcloud services vpc-peerings list komutunu çalıştırın.
PSC: Tüketici tarafında, bağlantı durumunu görmek için uç noktayı tanımlayın; üretici tarafında, bekleyen veya reddedilen bağlantıları ve ILB sağlığını kontrol edin. Hizmet eklentisinin (service attachment) tüketici izin listesini (allowlist) doğrulayın.
Cloud NAT: Çevirileri onaylamak için NAT günlüklerini ve metriklerini kullanın ve port tahsisi veya tükenmesi olup olmadığını kontrol edin. Bir sanal makinenin harici bir IP’si varsa, tasarım gereği NAT’ı atlar.

Pratik Problem Senaryosu

Contoso Research, iki bölgede (us‑east1, europe‑west1) analiz çalışmaları yürütmektedir. Güvenlik politikaları gereği hiçbir sanal makinenin genel (public) IP’si olmamalı, Google API’lerine özel olarak ve VPC Service Controls kapsamında erişilebilmeli, şirket içi kullanıcıların bir Cloud SQL örneğine (özel IP’li) özel erişimi olmalı ve bir iş ortağının SaaS hizmeti özel olarak kullanılmalıdır. Üçüncü taraf bir NGFW, varsayılan giden trafik için bir sonraki atlamadır (next hop).

Private Google Access ve kısıtlanmış uç noktaları etkinleştirme

Eylem: Tüm analiz alt ağlarında Private Google Access’i etkinleştirin. googleapis.com için Cloud DNS özel bölgeleri (private zones) oluşturun ve gerekli API’ler (BigQuery, Pub/Sub, Cloud Storage) için restricted.googleapis.com’a CNAME kayıtları ekleyin. Her iki bölgedeki varsayılan internet ağ geçidine 199.36.153.4/30 için ana makine rotaları ekleyin.
Gerekçe: Sanal makineden API’ye giden trafiğin özel kalmasını sağlar, VPC‑SC ile uyumludur ve geniş kapsamlı internet çıkışı oluşturmadan NGFW’yi atlar.

VPC Service Controls perimetresi oluşturma

Eylem: Analiz projelerini ve veri projelerini bir hizmet perimetresinin içine yerleştirin. Gerektiğinde Contoso kurumsal ağları için erişim seviyeleri ekleyin ve gelen trafik kuralları (ingress rules) aracılığıyla projeler arası gerekli akışlara açıkça izin verin. Kesin olarak gerekçelendirilmedikçe perimetre köprülerinden (perimeter bridges) kaçının.
Gerekçe: Google tarafından yönetilen hizmetlerden veri sızdırma riskini azaltır ve kısıtlanmış uç nokta kullanımıyla uyum sağlar.

Private Services Access ile Cloud SQL sağlama

Eylem: PSA için bir /24 aralığı ayırın, servicenetworking bağlantısını kurun ve us‑east1’de özel IP’li bir Cloud SQL örneği oluşturun. Interconnect üzerinden VPC rotalarını şirket içine yayın ve güvenlik duvarı kurallarına izin verin.
Gerekçe: Hem VPC iş yüklerinden hem de şirket içi istemcilerden genel kullanıma açmadan özel RFC1918 erişilebilirliği sağlar.

Google API’lerine şirket içinden özel erişim sağlama

Eylem: VPC’deki bir sonraki atlama (next hop) varsayılan internet ağ geçidi olacak şekilde, Cloud Router’dan şirket içine 199.36.153.4/30 anons edin. Şirket içi DNS’te, aynı API ana makine adlarını restricted.googleapis.com’a yönlendirin.
Gerekçe: Şirket içi istemcilerin aynı kısıtlanmış özel yolu kullanmasına olanak tanır, bu da tutarlı politika uygulanmasını sağlar ve operasyonel farklılıkları en aza indirir.

İş ortağının SaaS hizmetini Private Service Connect aracılığıyla kullanma

Eylem: İş ortağı, bölgesel bir hizmet eklentisi (service attachment) paylaşır. us‑east1 ve europe‑west1 alt ağlarında bu eklentiyi hedefleyen PSC uç noktaları oluşturun. Her bölgesel uç noktayı işaret eden özel A kayıtları (saas.partner.contoso) yayınlayın; bölgesel erişimi tercih etmek için ağırlıklı DNS (weighted DNS) kullanın.
Gerekçe: SaaS trafiğini, üretici tarafından zorunlu kılınan proje izin listeleriyle (allowlists) özel IP’lerde tutar, bölgesel yakınlık (regional affinity) aracılığıyla gecikmeyi iyileştirir ve genel internet çıkışını önler.

Google dışı internet çıkışı için Cloud NAT’ı koruma

Eylem: Bölge başına, en yoğun akışlar için boyutlandırılmış Cloud NAT ağ geçitleri dağıtın. Belirli kısıtlanmış VIP ana makine rotaları dışında, varsayılan rotanın hala NGFW’yi gösterdiğinden emin olun.
Gerekçe: Google API trafiğinin özel kalmasını ve NGFW’nin merkezi görünürlüğü korumasını sağlarken, Google dışı hedeflere kontrollü giden trafiğe izin verir.

Doğrulama ve izleme

Eylem: Her istemci türü için DNS çözümlemesini, rota seçimini ve TLS bağlantısını doğrulayın. Reddedilen istekler için VPC‑SC günlüklerini, Google dışı çıkışlar için NAT günlüklerini ve PSC bağlantı durumlarını kontrol edin. İş ortağının hizmet eklentisinin (service attachment) arkasındaki ILB’ler ve Cloud SQL için sağlık ve kullanılabilirlik uyarıları ekleyin.
Gerekçe: Veri yolunun tasarım amacına uygun olduğunu teyit eder ve özellikle DNS, rotalar veya perimetreler değiştiğinde regresyonları erken bir aşamada ortaya çıkarır.

← Cloud DNS · Tüm alanlar · Yönlendirme →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →