VPN üzerinden Google API: yalnız alt ağı değil VIP'i yönlendirin
VPC alt ağına giden rota API'nin VIP adreslerini seçmez. Doğru adları çözün, VIP önekini duyurun, VPC'de dönüş yolunu koruyun ve ardından HTTPS'i test edin.
SSH ile şirket içi sunucuya girin, tüneli kaldırın ve özel VM yanıt verir; ardından Google API'ye ilk çağrı rota olmadığı için başarısız olur. VM alt ağı ile API'nin VIP adresleri farklı hedeflerdir, bu yüzden birine ait rota diğerini seçmez. Özel bir API çağrısının çalışması için üç koşul sağlanmalıdır. API adı bir VIP'ye çözümlenmeli, VIP öneki tünel üzerinden duyurulmalı ve VPC yanıtı nasıl geri göndereceğini bilmelidir. Ping bunların hiçbirini söylemez, alt ağdaki bir makineye çalışan SSH oturumu da söylemez.
API'nin VIP adresleri ayrı hedeflerdir
Google, şirket içi ağdan API erişimi için özel VIP adresleri yayımlar ve API adları için DNS'inizin döndürmesi gereken adresler bunlardır. İkisi de küçük öneklerdir ve hiçbiri RFC 1918 alanı değildir:
| Record | Resolves to | What it does not give you |
|---|---|---|
| private.googleapis.com | 199.36.153.8/30, the general front door for Google APIs | not a bypass around a service perimeter |
| restricted.googleapis.com | 199.36.153.4/30, reachable only for services a perimeter allows | not the whole API surface, so some names stay out of reach |
Herkese açık görünen adresler, rotanın tünelden çıkması gerektiği anlamına gelmez sıradan internet için. Bu önekler, şirket içi istemcinin rastgele bir çıkış noktası yerine desteklenen bir yoldan Google'ın ön uçlarına ulaşması için vardır. Onları tünele ait hedefler olarak görün, araştırılacak sunucular olarak değil. İnternet çıkışı için yazılmış bir güvenlik duvarı kuralı genellikle onları düşürür ve bu, bir çağrının başlamadan önce başarısız olmasının yaygın bir nedenidir.
Hangi uç noktaya ulaştığınıza DNS karar verir
Yerel çözümleyiciyi seçilen uç nokta için Google'ın belgelediği kayıtlara yönlendirin, böylece uygulamanın gereksinim duyduğu adlar o VIP ile yanıt versin. Yalnızca googleapis.com eşlemek bir envanter değildir: paket kayıt defterleri, konteyner kayıt defterleri ve geçiş bağlayıcılarının kendi belgelenmiş adları vardır. Kısıtlı VIP de her hizmeti taşımaz, bu yüzden çözümlenen bir ad hâlâ desteklenmiyor olabilir. Çözümleyiciye dokunmadan önce uygulamanın gerçekte iletişim kurduğu alan adlarını yazın.
Bir hizmet adı yerine VPC'deki VM adresini tahmin etmek düzeltme değildir ve genellikle DNS boşluğunu başka bir istemci başarısız olana kadar gizler.
VIP önekini duyurun, gerisini koruyun
BGP tabanlı bir bağlantıda, şirket içi yönlendiricinin bu aralığı amaçlanan oturum üzerinden öğrenmesi için Cloud Router seçilen VIP önekini duyurmalıdır. Yalnızca VPC alt ağlarını duyurmak bu aralığı eklemez ve şirket içi yönlendirici bu adresler için varsayılan yolunu kullanmayı sürdürür. Yönlendirme tablosundaki önek, duyurunun oturumu geçtiğinin tek kanıtıdır.
Yenisini eklerken mevcut duyuruları koruyun, çünkü yönlendirici düzeyi ve eş düzeyi seçeneklerinin kapsamı farklıdır ve kümeyi değiştirmek zaten çalışan ağları geri çekebilir. Ardından etkin duyuruyu bir bütün olarak yönlendiricide değil, her oturumda denetleyin. Eksik önek ile geri çekilmiş önek şirket içi taraftan aynı görünür, bu yüzden atlamayı regresyondan ayıran oturum görünümüdür.
VPC tarafının kendi rotası ve dönüş yolu olmalı
VPC içinde VIP yolu, sonraki atlama olarak varsayılan internet ağ geçidini kullanmalıdır ve adına rağmen bu trafik Google'ın ağında kalır. VPC ayrıca VPN üzerinden şirket içi kaynağa dönüş rotasına ihtiyaç duyar ve bu, duyurulan önekten ayrı bir nesnedir. Tünel ile istemci aynı bölgede değilse belgelenmiş bölgesel yönlendirme gereksinimlerini hesaba katın.
Dönüş yolunu bağımsız olarak denetleyin, çünkü çalışan bir istek yönü bozuk bir yanıt yönünü gizleyebilir. İki yön, iki rota ve her biri kendi belirtisiyle başarısız olur.
İsteği test edin, sonra reddi okuyun
ICMP yankısı bu VIP'lerden yanıt almaz, bu yüzden başarısız bir ping hiçbir şeyi kanıtlamaz, başarılı olan ise çok azını. Gerçek istemciden adın yanıtını ve seçilen rotayı inceleyin, ardından önemsediğiniz hizmete yetkili bir HTTPS isteği yapın. İstek hizmete ulaşıp reddedilirse kimlik bilgilerine, IAM'e ve geçerli olan hizmet çevresi ilkesine bakın.
Özel yönlendirme API yetkisi vermez ve kimliğin ne yapmasına izin verildiğini değiştirmez. Taşıma başarısı ile yetkili bir yanıt ayrı sonuçlardır ve ikisine de ihtiyacınız var. IPv6 yolunu da açık tutun, çünkü IPv4 öneklerini yapılandırmak IPv6'yı tercih eden bir istemci hakkında hiçbir şey söylemez.
Google'ın şirket içi ağdan Private Google Access rehberi DNS kayıtlarını ve yönlendirme gereksinimlerini birlikte ele alır, bu yüzden çözümleyici ve duyuru ayarlarınızı bir forum gönderisiyle değil onunla karşılaştırın. Ardından aynı isteği yeniden çalıştırın ve yanıtı ve rotayı aynı bilette not edin.