Google PCNE: Hibrit Bağlantı, Cloud Router ve BGP — Ç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 Cloud’da hibrit bağlantı, VPC ağları ile şirket içi veri merkezleri veya diğer bulutlar gibi harici ağlar arasında özel ve kontrollü iletişimi mümkün kılar. Temel yapı taşları HA VPN ve Cloud VPN ağ geçitleri, dinamik yönlendirme için BGP’li Cloud Router ve VLAN eklerine sahip Interconnect’tir. Tasarımlar, deterministik yönlendirme davranışını ve hata etki alanı izolasyonunu takip ederken bant genişliği, gecikme süresi, güvenilirlik, operasyonel karmaşıklık ve maliyeti dengelemelidir. Bu bölüm, tasarım ve operasyonel mantığı, yaygın hata modlarını ve sistematik sorun gidermeyi kapsar.

Hibrit Bağlantı: HA VPN, Cloud Router ve Interconnect

HA VPN ve Cloud VPN
- HA VPN, IKEv2’yi destekleyen ve dinamik yönlendirme (eBGP) için Cloud Router gerektiren, bölgesel ve yüksek düzeyde kullanılabilir bir IPsec VPN’dir. Bir HA VPN ağ geçidinin iki arayüzü vardır; SLA ve ECMP için, her arayüze ayrı eş uç noktalara doğru iki tünel oluşturun.
- Classic Cloud VPN, IKEv1 veya IKEv2’yi ve statik veya rota tabanlı tünelleri destekler; HA VPN SLA’sını desteklemez. Yalnızca eşlerde BGP olmadığında veya ilke tabanlı seçiciler kullanmanız gerektiğinde kullanın.
- Eş ağ geçidi, uzaktaki VPN cihazı/IP’sidir. HA VPN için, yedeklilik amacıyla farklı arayüzleri veya cihazları modellemek üzere bir veya daha fazla genel IP’ye sahip bir eş VPN ağ geçidi tanımlayın.
- SLA tasarımı: HA VPN %99,99 SLA’sına uygun olmak için, bağımsız şirket içi cihazlar veya arayüzler arasında yedekli tüneller dağıtın ve dinamik yönlendirme kullanın. Classic VPN, SLA destekli değildir.
- Verim ölçeklendirme: Tek bir IPsec tünelinin sınırlı bir verimi vardır. Toplam verimi artırmak için birden çok tünel arasında ECMP kullanın. Bunu, ek tünelleri benzersiz eş genel IP’lerinde sonlandırarak başarın.
Cloud Router ve BGP
- Cloud Router, VPN tünelleri veya Interconnect VLAN ekleriyle BGP oturumları kuran ve rotaları dinamik olarak değiştiren bölgesel bir kontrol düzlemi hizmetidir.
- Dinamik yönlendirme modu (VPC düzeyinde), öğrenilen dinamik rotaların nerede kullanılabileceğini ve hangi VPC alt ağ rotalarının duyurulacağını yönetir:
  - Bölgesel (Regional): dinamik rotaları yalnızca aynı bölgede öğrenin ve kullanın/içe aktarın.
  - Genel (Global): dinamik rotaları tüm bölgelerde öğrenin ve kullanın/içe aktarın; tüm VPC alt ağ rotalarını (genel) eşlere duyurun.
Dedicated Interconnect ve Partner Interconnect
- Dedicated Interconnect, bir ortak yerleşim tesisinde (colocation facility) doğrudan Google’a fiziksel 10 Gbps veya 100 Gbps devreler sağlar. Çapraz bağlantıları (cross-connects) etkinleştirmek için bir Yetki Mektubu – Bağlantı Tesisi Ataması (Letter of Authorization – Connecting Facility Assignment - LOA-CFA) alırsınız. 802.1Q etiketlerini bir Cloud Router ile ilişkili bölgesel L3 bağlantısına eşleyen VLAN ekleri (interconnect attachments) oluşturun.
- Partner Interconnect, bir hizmet sağlayıcı aracılığıyla mantıksal bağlantı sağlar. İş ortağından VLAN ekleri talep edersiniz; bant genişliği iş ortağının ucunda (edge) sağlanır. BGP için ekleri yine de Cloud Router ile ilişkilendirin.
- Yedeklilik ve SLA: Daha yüksek SLA’lara (ör. %99,99) ulaşmak için aynı bölgede, farklı uç kullanılabilirlik alanlarına (edge availability domains) (ve geçerli olduğunda farklı fiziksel interconnect’lere) yerleştirilmiş iki ek kullanın. Tek bir ek veya bağlantı SLA’yı düşürür. Partner Interconnect için genel SLA aynı zamanda iş ortağına da bağlıdır.
Çapraz bağlantılar (Cross-connects) ve VLAN ekleri
- Çapraz bağlantılar (Cross-connects), bir buluşma odasında (meet-me room) sizin kafesiniz/ekipmanınız ile Google’ın kafesi arasındaki fiziksel fiber bağlantılardır. Bunları tamamlamak için LOA-CFA’yı sağlayıcınıza sunun.
- VLAN ekleri, bir VPC bölgesine yönelik mantıksal L2 sınırlandırmasıdır. Her ek:
  - Bir Cloud Router aracılığıyla tam olarak bir VPC ve bölge ile ilişkilendirilir.
  - Yedeklilik ve ECMP için çiftler halinde yapılandırılır.
  - Yalnızca L3 trafiği taşır; L2 uzantısı yoktur.

Kısa örnek:

Bir ek veya HA VPN eşi için Cloud Router ve BGP oluşturun: gcloud compute routers create cr-us-east1 –region=us-east1 –network=my-vpc –asn=65010 gcloud compute routers add-bgp-peer cr-us-east1 –region=us-east1 –peer-name=onprem-peer1 –peer-asn=65020 –interface=if-1 –peer-ip-address=169.254.0.2 –advertise-mode=DEFAULT –enable-bfd

Yönlendirme ve BGP Davranışı

Dinamik ve statik yönlendirme karşılaştırması
- Cloud Router ile dinamik yönlendirme, otomatik rota öğrenimi, yakınsama ve ECMP sağlar. Ağlar büyüdükçe ölçeklenir ve operasyonel yükü azaltır.
- Statik yönlendirme, peer’lerde BGP olmadığında veya dar kapsamlı, deterministik yollar için uygundur. VPC’de, statik rotaların sayısal bir önceliği vardır; aynı prefix uzunluğuna sahip statik rotalar arasında daha düşük değerler tercih edilir.
- Bir VPC’de rota seçimi:
  - En uzun prefix eşleşmesi kazanır.
  - Subnet rotaları, özel rotalar tarafından geçersiz kılınamaz.
  - Eşit prefix uzunlukları için statik rotalar en düşük önceliğe göre seçilir. Dinamik rotalar arasında ise Cloud Router, en iyi yolları yüklemeden önce zaten çözmüştür. Sistemin varsayılan rotası en az tercih edilendir.
BGP oturumları, yayınlama (advertisement) ve import/export
- Cloud Router, varsayılan olarak VPC subnet’lerini veya özel bir prefix setini export eder. Gerektiğinde 0.0.0.0/0 veya toplu prefix’ler yayınlayabilirsiniz, ancak bunu yapmak, politikalar izin veriyorsa on-prem trafiğini Cloud’a doğru çeker; tasarımı bilinçli yapın.
- Cloud Router, izin verilen tüm on-premises prefix’lerini import eder ve bunları VPC dinamik yönlendirme moduna göre dinamik rotalar olarak yükler.
- Peer başına yayınlanan rota önceliği, on-prem router’ların bir Google yolunu diğerine nasıl tercih edeceğini etkilemenizi sağlar; daha düşük öncelik değeri, peer’e doğru daha çok tercih edilen bir MED anlamına gelir.
ASN’ler, MED ve aktif-yedek (active-standby)
- Genel (public) ASN’ler gerekmedikçe her bir yönetimsel alan (administrative domain) için benzersiz bir özel (private) ASN kullanın. Aynı prefix’ler için aynı VPC’ye peering yapan birden fazla on-prem router için:
  - ECMP’yi veya tutarlı en iyi yolu (best-path) etkinleştirmek için, aynı prefix’leri yayınlayan tüm router’larda aynı on-prem remote ASN’i kullanın. Farklı remote ASN’ler, Cloud Router üzerinde eşit maliyetli (equal-cost) yüklemeyi engelleyebilir.
  - Aktif/yedek (active/standby) yapılandırması için, on-prem tarafından MED’i (daha düşük olan daha çok tercih edilir) manipüle edin veya on-prem’in birincil (primary) yolu tercih etmesi için Cloud Router’ın peer başına yayınlanan rota önceliğini ayarlayın. AS-path prepending bir alternatiftir ancak daha kaba bir araçtır.
Çok yollu (multipath) tasarım
- Cloud Router, hem HA VPN hem de Interconnect attachment’ları için birden fazla eşit BGP yolu üzerinde ECMP’yi destekler. Eşit öznitelikler (AS-path uzunluğu, MED, local-pref) ve farklı next hop’lar olduğundan emin olun. HA VPN için, tünelleri farklı peer IP’lerinde sonlandırın. Interconnect için, yedekli attachment’lar kullanın.

Dayanıklılık, Tespit ve Dışarı Yönelik (Egress) Servisler

BFD ve hata tespiti
- BFD, HA VPN ve Interconnect üzerindeki BGP oturumları için hata tespitini hızlandırır. Kararlılık ihtiyaçlarınıza uygun olarak saniye altı veya birkaç saniyelik tespit elde etmek için her iki tarafta da uyumlu aralıklarla BFD’yi etkinleştirin. IPsec tünellerinde IKE DPD ile birleştirin. Peer cihazlarınızın daha sık kontrol trafiğini işleyebildiğinden emin olun.
- Asimetrik tespitten kaçının: agresif BFD ayarları ve sıkışık bağlantılar oturumların kararsızlaşmasına (flap) neden olabilir; muhafazakar zamanlayıcılarla başlayın ve izleyin.
Yedekli topoloji desenleri
- HA VPN: Bölge başına bir HA VPN ağ geçidi kullanın ve tünelleri iki farklı on-prem cihaza veya arayüze sonlandırın. Bölge başına en az dört tünel (arayüz başına iki) ve bir Cloud Router oluşturun. ECMP sunarken remote ASN’leri tutarlı tutun.
- Interconnect: Her bölgede, farklı edge availability domain’leri üzerinde en az iki attachment kullanın. Dedicated Interconnect için, bağlantıları mümkünse farklı edge cihazlarına ve tesislerine dağıtın.
Cloud NAT, harici adresler ve özel iş yükü (private-workload) egress’i
- Cloud NAT, harici IP’leri olmayan kaynaklar için bölgesel, yönetilen bir egress hizmetidir. Harici IP’leri olan instance’lara SNAT uygulamaz; bu instance’lar doğrudan dışarı çıkar. Özel iş yüklerini kapsamak için bir bölgedeki subnet’leri veya tüm subnet’leri seçin.
- NAT IP havuzlarını eş zamanlı bağlantılar ve geçici (ephemeral) portlar için boyutlandırın; manuel veya otomatik IP atamasını seçin. Teşhis için loglamayı etkinleştirin.
- Google API’lerine özel olarak erişmek için:
  - VPC içi: Harici IP’leri olmayan VM’lerin Google’ın sanal IP’leri üzerinden Google API’lerine erişebilmesi için subnet’lerde Private Google Access’i etkinleştirin.
  - On-prem’den: On-prem istemcilerinin internetten kaçınarak özel hibrit bağlantılar üzerinden API’leri çözümleyip erişebilmesi için Google API’leri için Private Service Connect endpoint’lerini ve hibrit DNS’i kullanın.
- Eğer varsayılan rota üçüncü taraf bir güvenlik duvarını (firewall) gösteriyorsa ancak özel iş yüklerinin Google API’leri için bunu atlamasını istiyorsanız, ya Private Service Connect kullanın ya da yayınlanmış Google API IP aralıkları için varsayılan internet ağ geçidine (default internet gateway) daha yüksek öncelikli statik rotalar yükleyin ve bunu subnet’lerdeki Private Google Access ile birleştirin.
Hibrit DNS entegrasyonu
- VPC içi ad çözümlemesi için Cloud DNS özel bölgelerini (private zones) kullanın. On-prem’e genişletmek için:
  - Gelen yönlendirme (Inbound forwarding): on-prem çözümleyiciler, VPC’de barındırılan özel bölgeler için Cloud DNS’e yönlendirme yapar.
  - Giden yönlendirme (Outbound forwarding): VPC çözümleyicileri, seçilen domain’leri on-prem DNS’e yönlendirir.
  - Shared VPC veya çok projeli ortamlarda VPC’ler arası çözümleme için peering bölgeleri (Peering zones).
- Özel API erişilebilirliği için, API ana bilgisayar adlarını (hostname) Private Service Connect endpoint’lerine veya Private Google Access kullanırken uygun Google özel VIP’lerine eşleyen bir özel bölge (private zone) oluşturun ve bu adların on-prem’den DNS yönlendirmesi yoluyla çözülebildiğinden emin olun.

Planlama ve Sorun Giderme

Bant genişliği, gecikme süresi ve maliyet arasındaki ödünleşimler
- VPN: Dağıtımı en hızlı, sabit maliyeti en düşük, tünel başına verimi sınırlı, bit başına CPU/kripto ek yükü daha yüksek ve özel bağlantılara kıyasla genellikle daha yüksek gecikme süresi.
- Dedicated Interconnect: Öngörülebilir gecikme süresi ile en yüksek verim ve bit başına en düşük maliyet; daha yüksek sabit maliyetler ve tedarik süresi (çapraz bağlantılar, ortak yerleşim).
- Partner Interconnect: Orta yol; sağlayıcının ayak izinden yararlanır; SLA ve gecikme süresi, iş ortağının yoluna bağlıdır.
- Gecikme süresini en aza indirmek için eklentileri ve ağ geçitlerini bölgesel olarak iş yüklerine yakın yerleştirin. Birden çok hizmet projesine hizmet verirken bağlantıyı bir ana projede merkezileştirmek için Shared VPC kullanın.
- Trafik simetrisini, denetim gereksinimlerini ve hata etki alanlarını göz önünde bulundurun. Şirket içi son mil ve sağlayıcı yollarında tekil hata noktalarından kaçının.
Tünel, BGP ve yönlendirme sorunlarının sistematik teşhisi
1. Tünel kurulumu
  - IKE sürüm uyumluluğunu doğrulayın: HA VPN, IKEv2 gerektirir; eş yalnızca IKEv1 veya ilke tabanlı VPN destekliyorsa Classic VPN kullanın.
  - Paylaşılan gizli anahtarları, teklifleri (şifreleme, DH grupları), NAT-T’yi ve UDP 500/4500 bağlantı noktalarının erişilebilirliğini kontrol edin.
  - Eş IP’lerini ve yedeklilik için her tünelin ayrı bir eş arayüzünü işaret ettiğini onaylayın.
2. BGP oturum sağlığı
  - Her iki uçtaki BGP durumlarını onaylayın; Cloud Router durumunu inceleyin. BFD etkinse ancak oturumlar kararsızlaşıyorsa (flap), zamanlayıcıları gevşetin.
  - ASN yapılandırmasını doğrulayın; uyumsuz beklentiler ECMP’yi engelleyebilir veya en iyi yol sürprizlerine neden olabilir.
  - BGP oturumları için IP adreslemenin, tünel veya eklenti arayüzünde yapılandırılmış doğru bağlantı-yerel veya RFC1918 adreslerini kullandığından emin olun.
3. Rota değişimi ve yayılımı
  - Cloud Router reklam modunu (DEFAULT vs CUSTOM) kontrol edin. Beklenen alt ağların veya toplu rotaların dışa aktarıldığından emin olun.
  - Cloud Router üzerinde alınan rotaları inceleyin; AS-path, MED değerlerini değerlendirin. Aktif/bekleme hedefleniyorsa, MED veya reklamı yapılan rota önceliğinin bu amacı yansıttığından emin olun.
  - Öğrenilen rotaların gereken yerlerde görünmesi için VPC dinamik yönlendirme modunu (REGIONAL vs GLOBAL) doğrulayın. Alt ağ rotalarının geçersiz kılınamayacağını unutmayın.
  - Çakışmalar için, bir statik rota ve bir dinamik rota aynı ön ek uzunluğuyla eşleşirse, en düşük önceliğe sahip statik rota kazanır. İstenmediğinde çakışan statik rotaları ayarlayın veya kaldırın.
4. Veri düzlemi doğrulaması
  - Çıkış yolunu ve adres çevirisini doğrulamak için VPC Flow Logs ve Cloud NAT günlüklerini kullanın. Bir VM hala harici IP’si ile çıkış yapıyorsa, NAT’ı zorlamak için o harici IP’yi kaldırın.
  - Interconnect için, eklentinin operasyonel durumunu ve her iki eklentinin de yönetici tarafından etkinleştirildiğini ve doğru Cloud Router ile ilişkilendirildiğini doğrulayın.
  - Güvenlik duvarı kurallarının BGP ve uygulama trafiğine izin verdiğini onaylayın; Google sağlık kontrolü kaynak aralıklarının yük dengeleyici arka uçlarına ulaşmasına izin verilmesi gerektiğini unutmayın.
5. Interconnect devreye alma özellikleri
  - Konsoldan veya NOC iletişim e-postasından LOA-CFA’yı edinin. BGP’yi devreye almadan önce sağlayıcı ile çapraz bağlantı ışık seviyelerini ve VLAN etiketlemesini onaylayın.

Pratik Problem Senaryosu

Contoso Manufacturing, şirket içi fabrikalarını çevrimiçi tutarken ERP iş yüklerini Google Cloud’a taşıyor. Gereksinimler: Saniyenin altında yük devretme özelliğine sahip 20 Gbps özel bağlantı, merkezi yönlendirme kontrolü, şirket içinden Bulut’a aktif/bekleme çıkışı, genel internet olmadan Google API’lerine özel erişim ve minimum operasyonel ek yük.

Yaklaşım:

Aynı metropol içinde, farklı uç kullanılabilirlik alanları ve tesisler arasında iki adet Dedicated Interconnect bağlantısı dağıtın; bölge başına iki VLAN eklentisi (birincil ve ikincil) oluşturun ve bunları bölgesel bir Cloud Router ile ilişkilendirin.
- Gerekçe: Dedicated Interconnect, gereken toplam verimi ve öngörülebilir gecikme süresini sunar. Yedekli bağlantılar ve eklentiler, arızaları izole eder ve daha yüksek SLA için uygunluk sağlar. Birden çok eklenti, ECMP’yi ve trafik kaybı olmadan bakım yapmayı mümkün kılar.
Bölge başına, her eklenti için bir tane olmak üzere iki BGP eşi olan tek bir Cloud Router yapılandırın ve BFD’yi etkinleştirin.
- Gerekçe: Tek bir yönlendirici, birden çok sonraki atlama noktası üzerinden ECMP’yi desteklemeye devam ederken kontrol düzlemi yönetimini basitleştirir. BFD, arıza tespitini saniyelere indirerek ERP uygulaması için yakınsama RTO’sunu iyileştirir.
Google ile eşleşen her iki fabrika uç yönlendiricisinde de aynı şirket içi uzak ASN’yi standartlaştırın ve her birinden aynı ön ekleri reklam edin.
- Gerekçe: Eşleşen uzak ASN’ler, Cloud Router’ın istendiğinde eşit maliyetli yollar kurmasına ve yük dengelemesi yapmasına olanak tanır. Farklı ASN’ler kullanılsaydı, yalnızca bir rota kümesi kurulabilir ve bu da çoklu yol kullanımını engellerdi.
Şirket içinden Google’a MED kullanarak ve Google’dan şirket içine Cloud Router’ın reklamı yapılan rota önceliğini kullanarak aktif/bekleme tercihini uygulayın; birincil yollarda daha düşük değerler ayarlayın.
- Gerekçe: Çift taraflı ilke, deterministik yönlülük sağlar: fabrikalar Bulut’a ulaşmak için birincil metropolü tercih eder ve Contoso’nun VPC’si geri dönüş trafiği için birincil fabrika veri merkezini tercih eder. Bu, istenmeyen asimetriyi önler.
Paylaşılan VPC’de Google API’leri için Private Service Connect’i etkinleştirin ve API ana bilgisayar adlarını PSC uç noktasına eşleyen özel bir DNS bölgesi oluşturun; şirket içi çözümleyicilerin bu adları özel olarak çözümleyebilmesi için Cloud DNS gelen yönlendirmeyi yapılandırın.
- Gerekçe: PSC, Google API’lerine özel, VPC içi erişim sağlar. Hibrit DNS, bu uç noktalarını Interconnect üzerinden fabrikalardan erişilebilir hale getirerek ERP’nin destekleyici hizmetleri için internet maruziyetini ve güvenlik duvarı bağımlılıklarını ortadan kaldırır.
VPN yedeği için, her bölgeye farklı şirket içi cihazlara giden iki tünelli bir HA VPN ağ geçidi ekleyin; BGP oturumlarında BFD’yi etkinleştirin ve ECMP’ye izin verin.
- Gerekçe: Interconnect bozulursa, HA VPN özel erişilebilirliği sürdürür. Cihaz başına çift tünel, SLA ve verim sürekliliğini korur ve BFD, yük devretmeyi hızlandırır.
Özel iş yüklerinin internete ve Google dışı hedeflere çıkışı için, ERP alt ağlarında bölgesel Cloud NAT yapılandırın; VM’lere harici IP’ler atamayın.
- Gerekçe: Cloud NAT, VM yönetimi ek yükü olmadan çeviriyi ölçeklendirir ve özel adreslemeyi korur. Harici IP’leri kaldırmak, NAT’ın kullanılmasını garanti eder ve çıkış kontrollerini basitleştirir.
Yönlendirmeyi ve yük devretmeyi aşamalı testlerle doğrulayın: bir eklentiyi, ardından bir şirket içi yönlendiriciyi devreden çıkarın, ardından bağlantı bozulmasını simüle edin; BGP, BFD ve uygulama SLO’larını izleyin. Kararsızlık (flap) meydana gelirse BFD zamanlayıcılarını ayarlayın.
- Gerekçe: Kontrollü hata enjeksiyonu, tasarımın kurtarma hedeflerini karşıladığını doğrular ve üretimde sürprizleri önler. Zamanlayıcıları ayarlamak, kararlılık ve yanıt verme hızını dengeler.