Google PCNE: Yönlendirme, Network Connectivity Center ve Segmentasyon — Çalışma kılavuzu
Ş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ış
Bu bölüm, Google Cloud’daki yönlendirme, Network Connectivity Center (NCC) ve segmentasyon desenlerini açıklamaktadır. Bölümde, rotaların nasıl oluşturulduğuna ve seçildiğine, izolasyonu korurken VPC’lerin ve kuruluşların birbirine nasıl bağlanacağına, ölçeklenebilir transit ve hizmet ekleme tasarımlarının nasıl oluşturulacağına ve arızaların nasıl doğrulanıp kontrol altına alınacağına odaklanılmaktadır.
Yönlendirmenin temelleri ve kontrolü
Rota türleri
- Sistem tarafından oluşturulan alt ağ rotaları: Her birincil ve ikincil alt ağ aralığı için bir tane; tam ön ekleri için her zaman en çok tercih edilenlerdir.
- İnternet ağ geçidine varsayılan rota: Yeni VPC’lerde otomatik olarak oluşturulur; kaldırılabilir veya geçersiz kılınabilir.
- Statik rotalar: Varsayılan internet ağ geçidi, belirli bir sanal makine (instance), sonraki atlama noktası olarak bir dahili TCP/UDP yük dengeleyici (ILB) veya bir Cloud VPN tüneli gibi sonraki atlama noktalarına sahip özel ön ekler. İlke tabanlı rotalar, eşleşme koşulları (etiketler, hizmet hesapları, protokol/bağlantı noktası) ekler ve gelişmiş hizmet ekleme için bir sanal makineye veya ILB sonraki atlama noktasına yönlendirir.
- Dinamik rotalar: Cloud Router aracılığıyla BGP üzerinden Cloud VPN veya Cloud Interconnect’ten öğrenilir. Kapsamları, VPC’nin dinamik yönlendirme modu (bölgesel veya küresel) tarafından kontrol edilir.
Rota seçimi
- Önce en uzun ön ek eşleşmesi.
- Birden fazla rota aynı ön ek uzunluğuna sahipse, en düşük sayısal rota önceliği kazanır (özel rotalar için varsayılan 1000). Statik/dinamik yollar arasında eşit ön ekli çakışmalardan kaçının; birini net bir şekilde tercih edecek şekilde tasarlayın.
- Öncelik ötesindeki eşitlikler, platform içi eşitlik bozma mekanizmalarıyla çözülür; bunlara güvenmeyin.
Sonraki atlama noktası (next-hop) seçenekleri ve hizmet ekleme
- Giden trafiği (egress) merkezileştirmek veya L3/L7 hizmetleri eklemek için, 0.0.0.0/0 statik rotasını veya ilke tabanlı rotaları, arka uçları ağ sanal cihazları (NVA) olan bir ILB sonraki atlama noktasına yönlendirin.
- Harici IP’leri olmayan sanal makineler tarafından Google API’leri için cihazların atlanması gerektiğinde, alt ağlarda Özel Google Erişimi’ni (Private Google Access) etkinleştirin ve yayınlanan Google API’leri VIP aralıkları için varsayılan internet ağ geçidine özel statik rotalar ekleyin. Bu, diğer giden trafik NGFW yolunu izlerken Google hizmetlerine özel erişimi korur.
Dinamik yönlendirme modu ve çok bölgeli davranış
- Bölgesel: Bir Cloud Router tarafından öğrenilen rotalar yalnızca aynı bölgedeki alt ağlar için yüklenir.
- Küresel: Herhangi bir yerde öğrenilen rotalar, VPC’deki tüm bölgeler için yüklenir, bu da çok bölgeli basit bağlantı ve hub-and-spoke tasarımları için azaltılmış operasyonel yük sağlar. us-east1 ve europe-west1 yakınındaki kullanıcılar ve iş yükleri için, bölgesel alt ağlara ve küresel dinamik yönlendirmeye sahip tek bir VPC, RFC1918 üzerinden optimum verimlilikle özel olarak iletişim kurmalarını sağlar.
Rota ilanı kontrolü
- Cloud Router, tüm alt ağları veya özel bir ön ek kümesini (varsayılan bir rota dahil) şirket içine (on-premises) ilan edebilir. Standart BGP araçlarını (MED, AS-path prepending, şirket içi local preference) kullanarak şirket içine gelen yol seçimini kontrol edin. Şirket içine doğru aktif/yedek (active/standby) bir yapı için, birincil yolda daha düşük bir MED ve yedek yolda daha yüksek bir MED ayarlayın.
- Farklı ASN’lere sahip farklı şirket içi eşlerden (peer) aynı ön eki aynı Cloud Router’a ilan etmekten kaçının; çift bağlantılı ECMP veya temiz yük devretme (failover) için, yedekli şirket içi yönlendiricilerde aynı eş ASN’sini kullanın.
VPC ara bağlantısı ve segmentasyon
VPC Network Peering
- VPC’ler arasında düşük gecikme süresiyle ve veri düzlemi cihazları olmadan özel RFC1918 bağlantısı sağlar. Varsayılan olarak alt ağ rotalarını değiş tokuş eder ve Cloud VPN/Interconnect arkasındaki kaynaklara erişilebilirliği genişletmek için isteğe bağlı olarak özel rotaları (statik ve dinamik) içe/dışa aktarabilir. Geçişli yönlendirme (transitive routing) yoktur: bir eşten öğrenilen rotalar başka bir eşe yeniden dışa aktarılmaz.
- Arıza modları ve limitler: Çakışan CIDR’lar olamaz; güvenlik duvarı kuralları her VPC için bağımsız kalır; bant genişliği yüksektir ancak yük dengeleyicilerin yerini tutmaz; ağ (mesh) eşlemesi üzerinden asimetrik yönlendirme desteklenmez. Üç VPC’yi bir üçgen şeklinde bağlamak için, tam bir eşleme çifti ağı (full mesh) yapılandırın; Sales↔Finance ve Marketing↔Finance eşlemeleri, Sales↔Marketing çifti de eşlenmedikçe aralarında bağlantı sağlamaz.
- Adres planlaması: Otomatik modda bir VPC’yi (10.128.0.0/9 aralığını rezerve eden) eşlerken, eşi 10.0.0.0/9 gibi çakışmayan bir CIDR ile özel modda (custom mode) oluşturun.
Shared VPC ve çok projeli bağlantı
- Bir ana makine projesi (host project) VPC’ye sahiptir; hizmet projeleri (service projects) seçilen alt ağlara bağlanır. Bu, proje başına yetkilendirilmiş uygulama sahipliğini sağlarken ağ ve hibrit bağlantıyı (Cloud Routers, Cloud NAT, Interconnect) merkezileştirir. Tüm hizmet projelerine uygun maliyetli, merkezi şirket içi bağlantı sağlamak için VLAN eklerini (VLAN attachments) ve Dedicated Interconnect için Cloud Router’ları ana makine projesine yerleştirin.
- En az ayrıcalık ilkesi: Ağ Yöneticileri (Network Admins) yönlendirmeyi ve alt ağları yönetir; Güvenlik Yöneticileri (Security Admins) güvenlik duvarı kurallarını ve politikalarını yönetir. Ağ Yöneticisi ile güvenlik duvarlarını güncelleyemiyorsanız, Shared VPC kapsamında Güvenlik Yöneticisi yetkisi isteyin.
- Segmentasyon: Yalnızca bir hizmet projesinin gerektirdiği belirli alt ağları paylaşın. Bu, Üretim (Production) ve Hazırlık (Staging) ortamları arasındaki rota maruziyetini sıkı bir şekilde kontrol etmeye yönelik Google en iyi uygulamalarıyla uyumludur.
Ağ izolasyon kontrolleri
- VPC sınırları: Açıkça eşleme, VPN veya Private Service Connect olmadan VPC’ler arasında yönlendirme olmaz. Tamamen izole edilmesi gereken departmanlar veya kiracılar için ayrı VPC’ler kullanın; operasyonel yükü en aza indirmek için yalnızca bağlantı gerektirenleri eşleyin.
- Güvenlik duvarı politikaları: Tutarlı koruma önlemleri için kuruluş/klasör düzeyinde hiyerarşik güvenlik duvarı politikalarını ve yerel istisnalar için VPC başına kuralları kullanın. Varsayılan gelen trafiği reddetme/giden trafiğe izin verme (ingress deny/egress allow) kuralı daha da sıkılaştırılabilir.
- Çevreler (Perimeters): Google API’lerine erişimi kısıtlamak ve projeler ile ağlar arasında veri sızdırma risklerini azaltmak için VPC Service Controls’ü kullanın.
- IPv6 maruziyeti: Genel IPv6 erişimi için, hizmetinizin önünde yer alan küresel bir harici HTTP(S) yük dengeleyiciye IPv6 atayın. Arka uçlar (backends) özel kalır.
Network Connectivity Center ve transit mimarileri
NCC hub-and-spoke
- Hub, spoke’lar arasında yönlendirme için bir kontrol düzlemi (control-plane) sağlar. Spoke’lar arasında VLAN ekleri (Interconnect), HA VPN tünelleri, router appliance spoke’ları ve siteden siteye veri aktarımı için desteklenen VPC spoke’ları bulunur. NCC rota tabloları, hangi ön eklerin içe/dışa aktarılacağını ve hangi spoke’ların bunları alacağını kontrol ederek hassas segmentasyon sağlar.
- Siteden siteye veri aktarımı, şirket içi (on-prem) sitelerin hub’ı transit olarak kullanarak Google’ın omurga ağı üzerinden birbirine ulaşmasını sağlar. Bu, üçüncü taraf transit ihtiyacını azaltır ve operasyonları basitleştirir.
Router appliance spoke’ları ve üçüncü taraf NVA’lar
- Router appliance spoke’ları, Compute Engine üzerinde barındırılan sanal yönlendiricileri/güvenlik duvarlarını transit veya inline hizmetler olarak sisteme dahil eder. Birden çok appliance arasında ölçek ve sağlık denetimli yük devretme (failover) sağlamak için sonraki hop (next hop) olarak ILB kullanın.
- HA tasarımı: Farklı zone’larda en az iki appliance dağıtın; mümkünse bunları bir MIG ile bir ILB’nin arkasına yerleştirin; instance’larda IP yönlendirmeyi (IP forwarding) etkinleştirin; ILB next hop ile simetrik yönlendirme (symmetric steering) kullanın; etiketlere veya hizmet hesaplarına dayalı ilke tabanlı rotalar (policy-based routes) kullanarak yükü dağıtın.
- Verim ve hata toleransı ödünleşimleri: NVA’lar, instance türü ve NIC bant genişliği ile sınırlıdır; yatay ölçeklendirme için planlama yapın. Appliance hatası veya sağlık denetimi hatası, ILB’nin kaldırılmasını ve hızlı yük devretmeyi (fast failover) tetikler, ancak flap’leri (sık durum değişikliklerini) önlemek için rota yakınsama zamanlayıcılarının ve sağlık eşiklerinin ayarlandığından emin olun.
Transit topolojisi ödünleşimleri
- NCC ile Hub-and-spoke: Merkezi ilke, yüksek ölçeklenebilirlik, net etki alanı (blast-radius) kontrolü; rota tablosu tasarımı ve içe/dışa aktarma amacı gerektirir.
- Tam örgülü (Full mesh) eşleme: Az sayıda VPC için basittir, merkezi transit yoktur, ancak zayıf ölçeklenir ve geçişlilik (transitivity) veya hizmet ekleme (service insertion) sağlayamaz.
- Merkezi çıkış (egress): Tek bir NGFW veya NAT aracılığıyla basit güvenlik uygulaması; gecikme ekleyebilir ve bir darboğaz haline gelebilir; bölgesel çıkış noktaları ve otomatik ölçeklendirme (autoscaling) ile bu durum hafifletilebilir.
- Cloud Router’lar ile Mesh VPN: Esnek ve hızlı dağıtılır; eş (peer) sayısı arttıkça operasyonel ek yük artar; konsolide etmek için NCC’yi değerlendirin.
Cloud VPN ile ilgili dikkat edilmesi gerekenler
- Şirket içi (on-prem) cihazda BGP yoksa, statik rotalar ve dikkatle kapsamı belirlenmiş trafik seçiciler (traffic selectors) ile ilke tabanlı (policy-based) Cloud VPN kullanın; uzun vadeli ek yükü en aza indirmek için BGP’li HA VPN’e nihai geçişi planlayın.
- Şirket içine yönelik aktif/bekleme (active/standby) tüneller için, şirket içinde MED veya AS-path’i manipüle edin. Tek bir Cloud Router’a bağlanan çift şirket içi yönlendirici için, her iki yolun da kurulmasına ve ECMP’ye izin vermek amacıyla aynı eş ASN’leri tercih edin; farklı eş ASN’ler kullanmak genellikle yalnızca tek bir yolun seçilmesiyle sonuçlanır.
Operasyonlar: doğrulama, analiz ve kesinti kontrolü
Bağlantı doğrulaması ve rota analizi
- Sanal makineler, yük dengeleyiciler, VPC peering, Cloud VPN ve Interconnect arasındaki veri yolunu izlemek, güvenlik duvarı kurallarını ve rotaları doğrulamak için Network Intelligence Center’ın Connectivity Tests aracını kullanın.
- Sonraki atlama noktalarını (next hop) ve dinamik ön ekleri doğrulamak için sanal makine/alt ağ başına etkin rotaları analiz edin; dinamik yönlendirme modu kapsamının amaca uygun olduğunu doğrulayın.
- Performans veya kullanıcı deneyimi sorunları için, anycast giriş (ingress) ve uç sonlandırma (edge termination) yoluyla dünya çapındaki kullanıcılar için gecikmeyi azaltmak amacıyla global HTTP(S) load balancing’i tercih edin; network load balancer’lar bölgeseldir ve global gecikmeyi iyileştirmez.
Kesinti kontrolü ve etki alanının (blast radius) daraltılması
- Hataların veya yanlış yapılandırmaların istenmeyen şekilde yayılmasını önlemek için VPC’ler, NCC rota tabloları ve proje başına Shared VPC alt ağları ile segmentasyon yapın.
- Peering yoluyla geçişli (transitive) bağımlılıklardan kaçının; geçişin gerekli olduğu durumlarda, erişilebilirliği kısıtlamak için NCC ve kontrollü içe/dışa aktarma (import/export) kullanın.
- Temel engelleme/izin verme işlemleri için merkezi organizasyon düzeyinde güvenlik duvarı politikalarını, uygulama istisnaları için ise yerel politikaları kullanın; değişiklikleri Connectivity Tests ile test edin.
- Satır içi (inline) güvenliğin gerekli olduğu yerlerde, sorunsuz yük devretme (graceful failover) için sağlık kontrolleri (health checks) ve politika tabanlı yönlendirme (policy-based routing) ile bir sonraki atlama noktası (next-hop) olarak ILB dağıtın. Kritik Google API’lerine harici IP’lere dayanmadan Private Google Access veya Cloud NAT aracılığıyla erişilebildiğinden emin olun.
- BGP oturumlarını ve rota değişikliklerini izleyin; rota salınımını (route oscillation) ve asimetrik akışları önlemek için metrikleri (MED, local preference) ve adres planlarını standartlaştırın.
Kısa yapılandırma örnekleri
Trafiği satır içi bir ILB üzerinden yönlendirmek için statik bir rota oluşturma:
undefined
MED kullanarak şirket içi (on-prem) ağa gelen iki BGP yolundan birini tercih etme (şirket içi yönlendiricide):
undefined
-
undefined
-
undefined
-
undefined
Pratik Problem Senaryosu
Acme Retail, us-east1 ve europe-west1 yakınlarında iki kullanıcı popülasyonuna sahip çok projeli bir Google Cloud organizasyonunda faaliyet göstermektedir. Bölgeler arasındaki iş yükleri için özel, düşük maliyetli iletişim, merkezi şirket içi bağlantı ve internet çıkışı (egress) için satır içi URL filtrelemesi ihtiyaçları bulunmaktadır. Aynı zamanda Finans departmanının Mühendislik departmanından izole edilmesi gerekmektedir.
- Bir ana projede (host project) us-east1 ve europe-west1’de bölgesel alt ağlara sahip tek bir Shared VPC oluşturun ve dinamik yönlendirme modunu global olarak ayarlayın.
- Gerekçe: Tek bir VPC, bölgeler arasında peering ek yükü olmadan doğrudan RFC1918 iletişimini sağlar. Global dinamik yönlendirme, öğrenilen hibrit rotaları tüm bölgelere yükleyerek operasyonları basitleştirir ve verimli VPC içi akışlar sağlar.
- Her hizmet projesiyle (service project) yalnızca gerekli alt ağları paylaşın; Finans ve Mühendislik departmanlarını ayrı hizmet projelerine yerleştirin.
- Gerekçe: Alt ağ düzeyinde paylaşım, organizasyonel segmentasyon sağlar ve istenmeyen rota maruziyetini en aza indirir. Finans, Mühendislik alt ağlarının paylaşılmaması ve ayrı güvenlik duvarı politika kapsamları sayesinde izole kalır.
- Dedicated Interconnect’i ana projede sonlandırın ve Cloud Router’ları bağlayın; özel anonsları (custom advertisements) kullanarak yalnızca gerekli ön ekleri anons edin.
- Gerekçe: Merkezi hibrit bağlantı, şirket içi ağa nelerin ulaşacağını kontrol altında tutarken maliyeti ve karmaşıklığı azaltır. Özel anonslar, aşırı maruziyeti önler ve etki alanını (blast radius) daraltır.
- Bölgesel bir internal TCP/UDP load balancer’ın arkasına satır içi bir L7 URL filtreleme cihazı (appliance) ekleyin; her bölgede ILB sonraki atlama noktasına (next hop) giden bir 0.0.0.0/0 statik rotası ile çıkış trafiğini yönlendirin.
- Gerekçe: ILB next hop ve sağlık kontrolleri, cihazlar arasında simetrik akışlarla yüksek erişilebilirlikli (HA) hizmet ekleme (service insertion) sağlar. Varsayılan rotadan daha yüksek önceliğe sahip statik rotalar, tüm çıkış trafiğinin filtrelenmesini garanti eder.
- Harici IP’si olmayan örneklerin (instance) Google API’lerine doğrudan ulaşabildiğinden emin olun: tüm alt ağlarda Private Google Access’i etkinleştirin ve cihazı atlamak için Google API’leri VIP aralıklarına yönelik statik rotaları varsayılan internet ağ geçidine (default internet gateway) ekleyin.
- Gerekçe: Private Google Access, BigQuery ve Pub/Sub’a özel erişimi korur; özel rotalar, filtre üzerinden gereksiz geri dönüşleri (hairpinning) önleyerek maliyeti ve gecikmeyi azaltır.
- Finans departmanını izole tutun: hiyerarşik güvenlik duvarı politikalarında projeler arası trafiği engelleyin ve Finans ile Mühendislik arasında peering yapılandırmayın. Mühendislik↔Analitik işbirliğinin gerekli olduğu durumlarda, çakışmayan CIDR’lere sahip özel bir eşleştirilmiş (peered) VPC çifti oluşturun.
- Gerekçe: VPC sınırları, peering’in olmaması ve organizasyon düzeyindeki güvenlik duvarı politikaları izolasyonu zorunlu kılar. Hedeflenmiş peering, geçişlilik (transitivity) olmaksızın belirli departman bağlantıları için düşük operasyonel ek yük sunar.
- Doğrulayın ve izleyin: bölgeler arası erişilebilirliği ve cihaz eklemeyi doğrulamak için Connectivity Tests’i kullanın; Cloud Router BGP sağlığını ve rota tablolarını izleyin; birden fazla tünel varsa aktif/yedek (active/standby) yük devretme için şirket içi yönlendiricilerde MED uygulayın.
- Gerekçe: Proaktif doğrulama, yanlış yapılandırmaları erken tespit eder. BGP kontrolleri, bakım veya arızalar sırasında şirket içi yolları deterministik tutarken, NCC/Cloud Router telemetrisi sorun gidermeyi hızlandırır.
Bu tasarım, Acme Retail’in gereksinimlerini minimum maliyet ve yüksek verimlilikle karşılar: tek bir VPC’de özel çok bölgeli yönlendirme, merkezi hibrit bağlantı, kontrollü hizmet ekleme ve güçlü organizasyonel segmentasyon.
← Google’a Özel Bağlantı ve Yönetilen Hizmetler · Tüm alanlar · GKE →
Bu soruları çözün → · ExamRoll.io’da süreli pratik →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Sınavınızı geçin →