EC2 üzerinde strongSwan: VPC iş yükünü yönlendirsin

Tünel ayakta, şlüz örneği uzak ağa ping atabiliyor ve yanındaki uygulama örneği hiçbir yere ulaşamıyor. Hiçbir şey bozuk değil. Başarılı test VPN ana bilgisayarında başladı ve o ana bilgisayarın aynı IPsec ilişkisi üzerinden farklı bir kaynak adresi taşıyıp taşıyamayacağını hiç sormadı. Bu kılavuz o boşluğu dört adımda kapatıyor, her arızayı görünür tutan sırayla.

Önce dört adresi yazın

Aşağıdaki her adım bunlara atıfta bulunur, bu yüzden bir yönlendirme tablosuna dokunmadan önce kendi hesabınız için doldurun.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

Örnek, onaylanmış ve çalışan ilke tabanlı bir IPsec bağlantısı ile kaynağı koruyan bir akış varsayar. Bu, atanmış tek bir adresi ödünç alan NAT'lı bir uzaktan erişim istemcisi değildir ve bu fark, seçicilerin değişmesi gerekip gerekmediğini belirler.

Adım 1: iş yükü alt ağına bir rota verin

İş yükü alt ağıyla gerçekten ilişkilendirilmiş yönlendirme tablosu, uzak önek için şlüzün ağ arayüzüne işaret eden bir yola ihtiyaç duyar. Örneğin içine kurulan konuk rotası o AWS yönlendirme tablosunda bir kayıt değildir ve hiçbir strongSwan yapılandırması bir tane oluşturmaz.

AWS'nin cihaz üzerinden yönlendirme rehberi, ağ arayüzü hedeflerini ve ileten örneğin kaynak/hedef denetimi gereksinimini açıklar. Bu denetim değişikliğini şlüz rolüyle sınırlayın ve sıradan uygulama örneklerini rahat bırakın.

Bir onaylı ağa yer açmak için VPC'nin yerel rotasını veya mevcut her kaydı değiştirmeyin. Kimsenin kullanmadığı bir yönlendirme tablosu için konsol sayfasının gösterdiğine değil, neyin ilişkilendirilmiş ve etkin olduğuna bakın. Benzer görünen iki tablonun farklı ilişkilendirmeleri olabilir. Önemli olan, iş yükü alt ağının bağlı olduğu tablodur.

Adım 2: konukta iletmeyi açın

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

Çekirdek iletmeli ve ana bilgisayarın güvenlik duvarı geçişe izin vermelidir. Her şeyi kabul etmek yerine iş yükü ve uzak önekler için amaçlanan iletme kurallarını ekleyin ve şlüz alt ağının kendi trafiği için kullanılabilir bir taşıma rotası koruduğunu doğrulayın.

Güvenlik grupları bu adımın genellikle tıkandığı yerdir. Bir ara cihaz, doğrudan örnek iletişiminin güvenlik grubu referans davranışını devralmaz, bu yüzden yönetilen bir Client VPN örneğinden kopyalanan kural hiçbir zaman eşleşmeyebilir. Gerçek yolda güvenlik grubunu ve alt ağ ACL'sini iki yönde de kontrol edin.

Adım 3: seçicileri gerçek kaynaklara genişletin

AWS tarafında yalnızca 10.60.1.10/32 adresini kapsayan bir ilke, 10.60.2.20 adresini kapsamadan şlüzden başlayan bir başarıyı açıklar. Uzak hedefe giden bir rota trafik seçicisini genişletmez ve bu, aynı sürprizin ikinci yarısıdır.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

Kararlaştırılan tasarım tüm VPC'yi koruyorsa, her iki eş de 10.60.0.0/16 ve 10.90.0.0/24 adreslerini kabul etmelidir. Tek bir iş yükünü koruyorsa, o daha dar öneği bilinçli olarak kullanın. Her durumda, kurulu CHILD-SA ilkesini inceleyin, çünkü düzenlediğiniz yapılandırma ile onu farklı şekilde daraltan bir eş aynı anlaşma değildir.

Uzak site ayrıca korunan VPC kaynakları için yanıtları amaçlanan IPsec şlüzünden geri yönlendirmelidir. Başka kaynak NAT kurallarının bulunduğu yerlerde korunan trafik için desteklenen NAT muafiyetini koruyun; onaylanmamış bir iş yükünü izin verilen bir ana bilgisayar adresine çevirmek başka bir kimlik sözleşmesidir, istediğiniz erişime kısa yol değil.

Adım 4: doğrulayın, gerekirse geri alın

İş yükünün kendisinden yeni ve izin verilen bir uygulama işlemiyle test edin, ardından dışlanması gereken bir hedefle tekrarlayın. Uzak hizmetin gördüğü kaynak adresi ve kullandığı dönüş yolunu kaydedin. Bir şlüz pingi veya yeşil IKE durumu o test değildir.

Şlüz çalışırken iş yükü hâlâ başarısız oluyorsa adımlarda sırayla geri gidin: seçici, ardından iletme ve güvenlik grupları, ardından ilişkili yönlendirme tablosu. Her birinin farklı bir belirtisi vardır ve tahmin etmek aslında yanlış olanı atlar.

Geri alma aynı sırayı tersine çevirir. İş yükü alt ağının rotasını en son kaldırın, önceki seçicileri geri yükledikten sonra, böylece kaynaklarını artık korumayan bir şlüze işaret eden bir alt ağ bırakmayın. Bu sözleşmeler geçerli olduğunda kendi kendine barındırma şlüz ana bilgisayarından fazlasına hizmet edebilir ve AWS tarafından yönetilen Site-to-Site VPN, strongSwan'ın bunun yerine müşteri şlüzü tarafında oturabileceği farklı bir işletim modelidir.