Bir geliştiricinin bir SSH oturumuna, bir veritabanı bağlantı noktasına veya bir düzine özel hizmete geniş erişime ihtiyacı vardır ve bu isteklerin her biri aynı soru gibi görünür. Değildir. Hedefler, protokoller ve ilgili kimlikler Google Cloud'da hangi erişim yolunun uygun olduğuna karar verir ve varsayılan olarak en geniş olanı seçmek, sahip olmanız gerekmeyen iş yaratır.

Hedefleri ve protokolleri yazın

İşin gerçekten ihtiyaç duyduğu özel adresleri, bağlantı noktalarını ve protokolleri listeleyin, ardından hangi kimliklerin ayrı ayrı doğrulanması gerektiğini işaretleyin. Bir veritabanı bağlantı noktası ile özel bir DNS bölgesi farklı gereksinimlerdir ve bir UDP hizmeti aşağıdaki seçeneklerden birini tamamen dışlar. Yazılı bir liste aynı zamanda neyi vermediğinizi de gösterir. İnceleyicilerin sorduğu kısım budur.

Bunu bir dinleyici açmadan önce yapın. Liste daha sonra kabul testi haline gelir ve dar bir tüneli tesadüfen çalışan geniş bir tünelden ayırmanın tek güvenilir yolu budur.

Birkaç TCP hizmeti için IAP

Identity-Aware Proxy'de TCP yönlendirme, hizmeti internete maruz bırakmadan uygun VM kaynaklarına doğrulanmış bir tünel sağlar. Günlük biçim gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a şeklindedir ve tek bir bağlantı noktası gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a ile yerel olarak yönlendirilebilir.

Üç şeyin uyuşması gerekir: çağıranın IAP tüneli erişim rolüne ihtiyacı vardır, güvenlik duvarı IAP kaynak aralığını kabul etmelidir ve hedef örnek üzerinde erişilebilir olmalıdır. Tüneli oluşturma yetkisi bir veritabanı kimlik bilgisi, SSH oturumu açma veya RDP oturumu değildir, bu yüzden uygulama kimlik doğrulamasını olması gereken yerde tutun.

IAP'de TCP yönlendirme üçüncü katman VPN değildir. TCP'yi seçilen hedefe taşır, rastgele IP trafiğini veya UDP'yi değil, ve bir uygulamanın birçok hizmette özel DNS'e ihtiyaç duyduğu durumlarda iyi uymaz.

Daha geniş erişilebilirlik için uzaktan erişim VPN'i

Birden çok hedef, protokol veya özel DNS bölgesi gerektiğinde, bir VM veya desteklenen cihaz üzerinde açıkça yönetilen uzaktan erişim VPN'i daha iyi biçimdir. Bu dağıtım Google'ın yönettiği Cloud VPN'den ayrıdır: istemci kimliği kaydı, yazılım güncellemeleri, istemci yolları ve VPC'deki dönüş yolları size aittir.

Yalnızca genel dinleyiciyi değil, tüm listeyi planlayın. Tünel havuzunu, ona geri dönen VPC yolunu, yönlendirme denetimlerini, DNS çözümlemesini ve hizmet başına erişim politikasını ekleyin. Bağlanan ancak iç adları çözemeyen bir VPN, geliştiricinin iş akışını hiç bağlanmayan bir VPN kadar tamamen başarısız kılar.

Cloud VPN bir site ağ geçididir, dizüstü profili değildir

Google Cloud VPN, eş ağ geçitlerini IPsec üzerinden bağlar ve sık sorulan sorular bölümü bu site-site rolünü istemci-ağ geçidi erişiminden ayırır. Tünel oluşturmak, bir çalışanın dizüstü bilgisayarına aktardığı bir profil üretmez. Biri Cloud VPN profili istediğinde bu ayrım önemlidir. Cevap başka bir üründür.

Bir ağ geçidinin iyi yaptığı şey, ofis ağı arkasındaki makinelere VPC'ye giden bir yol vermektir. Her çalışanı doğrulamaz ve uygulama izinleri vermez, bu yüzden bu politikalar kimlik başına uygulanabildiği ağ ve uygulama katmanlarında kalır.

Doğrulayın ve kaydedin

Önce en dar hedefi, sonra DNS gerektireni ve sonra reddedilmiş kalması gereken bir hedefi test edin. Her testi üretimde yolu kullanacak aynı istemciden çalıştırın, çünkü bir yönetici iş istasyonundan çalışan bir test, farklı bir ağa sahip geliştirici dizüstü bilgisayarı hakkında çok az şey kanıtlar.

Seçilen modeli, kapsadığı hedefleri, doğruladığı kimlikleri ve yol kullanılamadığında hata davranışını kaydedin. Bu kayıt, bir sonraki isteğin belgelenmiş bir tasarıma bir hedef eklemek yerine tüneli sessizce genişletmesini önleyen şeydir.

İlgili makaleler