AWS’den Azure’a site-to-site VPN: önce dönüş yolunu yazın
İki bulut arasında bağlanan bir tünel, her iş yükü alt ağı uzak öneke yönlendirmedikçe hiçbir şeyi kanıtlamaz. Planı sırayla uygulayın, sonra hizmeti test edin.
Tünel ayağa kalkar. Genelde kalkar, çünkü IKE yalnızca eşleşen önerilere ve erişilebilir bir eş adresine ihtiyaç duyar. Sonrasında başarısız olan şey dönüş yoludur: AWS iş yükü paketleri bir tünele gönderir, ama Azure tarafında kimse 10.10.0.0/16’ya nasıl yanıt verileceğini bilmez ya da Azure rotası, iş yükü alt ağının kullanmadığı bir tabloda durur. Herhangi bir konsola dokunmadan önce rota planını yazın; tünel işin en az ilginç kısmı olur.
Adım 1: adres planını dondurun
Somut değerlerle çalışın. Bir AWS iş yükü 10.10.0.0/16 içinde 10.10.1.20’de oturur ve 10.20.0.0/16 içindeki 10.20.1.30 adresindeki Azure hizmetine TCP 443 gerekir. İki aralık çakışmamalıdır ve kabul testi tünel değil, hizmet çiftidir.
Bu dört gerçeği her şeyden önce yazın, çünkü sonraki her adım onlara göre denetlenir.
Adım 2: her uca sahip olan ağ geçidini adlandırın
AWS Site-to-Site VPN bir sanal özel ağ geçidinde veya bir transit ağ geçidinde sonlanabilir ve bunlar farklı yönlendirme sahipleridir. Azure, yönetilen VPN Gateway’ini ve ayrıca müşterilerin kendilerinin işlettiği VM tabanlı cihazları sunar. Hangi çifte sahip olduğunuzu not edin, çünkü sonraki atlama her kombinasyonda farklıdır.
Yönetilen ağ geçidi için, tahmin edilen özel cihaz adresini gösteren bir rotayı kopyalamayın. Bir cihaz için, buluttaki rota yayılımının konuk işletim sistemini yapılandırdığını varsaymayın, çünkü yapılandırmaz.
Burada hata yapmak, eksiksiz görünen bir plan üretir ve paketleri asla yanıt vermeyen bir adrese gönderir.
Adım 3: her iş yükünün gerçekten kullandığı rotayı yazın
Aşağıdaki her sınır ayrı bir aramadır ve bunlardan birindeki rota paket için rota değildir. Tünel devreye girmeden önce tabloyu kendi değerlerinizle doldurun.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
AWS’de iş yükü alt ağının rota tablosunu BGP veya tünel sağlıklı olduktan sonra bile siz güncellersiniz; yönlendirme genel bakışı bunu bağlantının parçası sayar. Azure’da kullanıcı tanımlı rota tablosu sanal ağa değil bir alt ağa bağlanır, bu yüzden etkin rotayı VNet dikey penceresinde değil, iş yükünün NIC’inde denetleyin.
Yönetilen bir Azure ağ geçidi uzak öneki ağ geçidi yayılımıyla öğrenebilir ve bir UDR bu kararı geçersiz kılabilir. UDR’yi bir nedeniniz olduğunda ekleyin, refleks olarak değil. Eklerseniz, cihaz adresi uydurmak yerine ağ geçidinin VPN yolu için yayımladığı sonraki atlamaya yönlendirin. Sonra NIC’teki etkin rotaları yeniden okuyun, çünkü karar gerçekte orada verilir.
Adım 4: kapsamı uzlaştırın
BGP için her tarafın duyurduğunu diğer tarafın gerçekten öğrendiğiyle önek önek karşılaştırın. Statik yönlendirme için yapılandırılmış uzak aralıkları 3. adımda yazdığınız iş yükü rotalarıyla karşılaştırın.
Kriptografi üzerinde anlaşan bir IKE ilişkisi, herhangi bir tarafın 10.10.0.0/16 veya 10.20.0.0/16 öğrendiğinin kanıtı değildir. Bir taraf planladığınız /16 yerine tek bir /24 duyururken iki tünel ayakta olabilir. Öneki tünel durumunda değil, yönlendirme tablosunda denetleyin. Uyumsuzluk sonra çalışan bir alt ağ ve asla yanıt vermeyen bir başkası olarak görünür.
Adım 5: hizmeti gerçek kaynaktan test edin
Amaçlanan akışa AWS güvenlik gruplarında ve ağ ACL’lerinde, Azure NSG’lerinde ve yoldaki herhangi bir cihaz filtresinde izin verin. Sonra 10.10.1.20’den onaylanmış hizmet adresine ve bağlantı noktasına bir bağlantı açın ve yanıtın aynı kaynağa döndüğünü doğrulayın.
Bulut güvenlik grupları da NSG’ler de durum bilgisi tutar, bu yüzden reddedilen dönüş paketi yönlendirme belirtisidir, ters yönde yazmayı unuttuğunuz bir kural değil.
Herhangi bir ağ geçidinden ping hiçbir şeyi çözmez. Ağ geçidi adresine ICMP kontrol düzlemi yolunu çalıştırır, iş yükünün ihtiyaç duyduğu iletilen TCP hizmetini değil.
Geri alma ve kayıtlar
Rota sahiplerini tünel tanımlayıcılarının yanına kaydedin ve değişiklik öncesi rota tablolarını saklayın. Değişikliğin geri alınması gerekiyorsa, tüneli sökmeden önce iş yükü rotalarını kaldırın, böylece artık var olmayan bir sonraki atlamayı gösteren alt ağ kalmasın.
O zaman sonraki bir alt ağ taşıması veya spoke bağlantısı güncellenecek tek bir tanımlı yere sahip olur; hiç sahip olmadığı bir rotanın suçunu taşıyan çalışan bir tünel yerine.