VPC'ye VPN çalışıyor, ancak yönetilen hizmet zaman aşımına uğruyor

Yönetilen bir veritabanına VPN üzerinden erişmek genellikle kimsenin runbook'a yazmadığı bir nedenle başarısız olur: tünel ağınızın kenarında biter, oysa hizmet hiçbir zaman onun sizin tarafınızda olmamıştır. Yönlendirme tablosu doğru görünür, tünel çalıştığını bildirir ve bağlantı yine de zaman aşımına uğrar. Aşağıdaki dört kontrolü sırayla yapın ve geçiş koşulu sağlanmayan ilk kontrolde durun, çünkü sonraki her kontrol öncekilerin geçtiğini varsayar.

Kontrol bir: uç nokta gerçekte nerede yaşıyor?

VPN ağ geçidi, adreslemesini sizin denetlediğiniz iki ağı birleştirir. Yönetilen hizmet, sağlayıcının kendi ön kapısının arkasında işletilir ve o kapı ürüne göre üç biçimden birini alır. Hangi biçimle karşı karşıya olduğunuzu bilmiyorsanız, hiçbir rota çalışması yardımcı olmaz, çünkü arıza bir rota arızası olmayabilir.

Harcanan öğleden sonraların çoğu bu sınıflandırmayı atlayıp doğrudan yönlendirme tablosuna gitmekten kaynaklanır. Genel uç noktası olan sağlayıcıda barındırılan bir hizmet, şema ne derse desin tünelinizin arkasında değildir ve VPC'ye bağlı olan asla genel bir DNS yanıtında görünmez.

Kontrol iki: ElastiCache gibi VPC'ye bağlı bir hizmet

Bu tür önbellekler kendi VPC'nizin içinde adreslenir ve internete bakan hiçbir dinleyicileri yoktur. Aynı VPC'de biten bir istemci VPN onlara ulaşabilir, ancak yalnızca üç koşul aynı anda sağlandığında. Önbelleğin uç noktası tünelinizin görebildiği alt ağlarla ilişkilendirilmeli, güvenlik grubu istemcilerinizin geldiği adrese izin vermeli ve istemci tarafında önbellek alt ağlarını kapsayan bir rota bulunmalıdır.

Yaygın hata, yakınlardaki bir bağlantının da sayıldığını varsaymaktır. VPN'i başka bir VPC'ye bağlamak veya yalnızca peering'e güvenmek, önbelleğin güvenlik grubunu ya da alt ağının yönlendirme tablosunu istemcilerinize genişletmez. Mevcut tünel başka bir yerde bitiyorsa, o VPC'nin içine yerleştirilmiş bir atlama sunucusu veya VPN sunucusu olağan yedektir. Böyle bir yedek bir tasarım değil, bir dolambaçtır ve runbook'ta böyle işaretlenmelidir.

Kontrol üç: genel adı olan bir PaaS uç noktası

Azure Database for PostgreSQL genel bir sunucu adı sunar. Bir hosts dosyasına sabitleyip ağ geçidi üzerinden yönlendirebileceğiniz özel bir adres vermez. Sanal ağ hizmet uç noktaları hangi alt ağların bir kaynağa ulaşabileceğini sınırlar; VPN üzerinden gelen şirket içi istemciye yetki vermez.

Özel erişim elde etmek, özel bir uç nokta veya özel bağlantı tasarımı getirmek ve ardından genel adın internet yerine o uç noktayla yanıt vermesi için özel bir DNS bölgesi eklemek demektir. Bir VPN'in hizmet uç noktası kuralıyla birleşimi, yalnızca şemada benzeyen başka bir mimaridir. App Service aynı mantığı ters yönden izler: VNet tümleştirmesi uygulamanın VNet'e giden çağrılar yapmasına izin verir ve tünelinizden gelen özel bir yolu oluşturmaz. Bu nedenle gelen özel erişim özel bir uç nokta, bir App Service ortamı veya uygulamanın önünde bir ağ geçidi gerektirir ve bunlardan hangisini kullanabileceğiniz plana bağlıdır.

Kontrol dört: kendi ön kapısı olan ürünler

Firebase Hosting bir Cloud VPN'e bağlanamaz, çünkü barındırma katmanı küresel bir ön uçtur ve bir projenin VPC'sinin içindeki bir şey değildir. Belgelenen alternatif, denetlenen giriş noktasını kendiniz inşa etmektir; bir proxy örneği veya bir kovayla desteklenen yük dengeleyici ile. Her durumda site saf bir barındırma ürünü olmaktan çıkar ve artık sizin işlettiğiniz altyapıya dönüşür. Bu takas, biri tünelin onu kapsayacağını vaat etmeden önce adlandırılmaya değer.

Private API Gateway, VPC hizmetleri tarafına daha yakındır: interface türünde bir VPC uç noktası, yanıtları özel adresler olan bir ana bilgisayar adı yayımlar ve tesisinizden gelen trafik tünel veya özel bir ara bağlantı üzerinden ulaşır. Uç nokta API'ye bağlı olmalı ve sertifika ile ana bilgisayar adı, çağıranların kullandığı özel alan adıyla eşleşmelidir.

Google Cloud VPN tünelleri adlara değil, eş IP adreslerine bağlanır. DNS yönlendirmesi ayrı yapılandırılır, bu yüzden bir tünel tamamen sağlıklı olabilirken uzak özel bölgedeki aramalar hâlâ başarısız olur.

Ardından sınırı belirleyin

Aynı bağlantıyı VPC içindeki bir VM'den çalıştırın. Orada başarılı olup VPN istemcisinden başarısız olursa, boşluk istemcinin yolu ile hizmetin uç noktası arasındadır: bir rota, bir güvenlik grubu, bir uç nokta ilkesi veya bir ad. İki deneme de başarısız olursa o ağdaki hiçbir şey hizmete ulaşamaz ve VPN hiçbir zaman engel değildi.

getent hosts db.internal.example
nc -vz db.internal.example 5432

Ad sorgusunu ve bağlantı noktası kontrolünü ayrı ayrı yapın, çünkü farklı nedenlerle başarısız olurlar ve bu çift size yolun hangi yarısının bozuk olduğunu söyler. Genel bir adrese çözülen bir ad, özel DNS bölgesinin işin içinde olmadığını size söyler.