VPN istemci IP'lerini bulut sınırında koruyun veya SNAT uygulayın

VPN istemcisinin adresini uygulamaya kadar korumak, her günlük satırının ve izin listesindeki her girişin aynı anlama gelmesini sağlar. Adresi bulutun kenarında yeniden yazmak yönlendirme tablosunu basitleştirir ve günlükleri daha az işe yarar hale getirir. İki seçenek de kendi başına yanlış değildir ve bunu belirleyen argüman nadiren performansla ilgilidir. Üç koşul belirler: uygulamanın hangi insanın bağlandığını bilmesi gerekiyor mu, bulut dokusu göndermeyi düşündüğünüz kaynağı kabul edecek mi ve geri dönüş yolunun sorumluluğunu sonradan kim üstlenecek.

Üç koşul belirler

Ağ şemasıyla değil, uygulamanın gereksinimiyle başlayın. Yetkilendirme veya denetim bireysel istemci adresine bağlıysa, onu korumak işlevsel bir gereksinimdir ve çevirmek bir gerilemedir. Uygulamanın yalnızca trafiğin uzaktan erişim yolundan geldiğini bilmesi gerekiyorsa, çevrilmiş adres yeterlidir ve işletmesi çok daha ucuzdur.

İkinci koşul mekaniktir. Sanal bir ağ, gönderen arayüze atanmamış bir adres iddia eden pakete otomatik olarak güvenmez. Çoğu bulut dokusu bunu farklı biçimlerde ve adlarla zorunlu kılar ve bunu yok sayan bir tasarım şemada doğru görünür, üretimde ise sessizce düşer.

Üçüncüsü örgütseldir. Kaynakları korumak, uygulama alt ağının yönlendirme tablosunun istemci öneki için ağ geçidine geri işaret etmesi gerektiği ve sonradan alt ağ ekleyen her ekibin bu rotayı tutarlı tutması gerektiği anlamına gelir. Bu bir kez küçük bir maliyet ve düzinelerce hesapta yinelenen bir maliyettir. Davranışı vaat etmeden önce kimin ödeyeceğine karar verin.

Rota, sahtekârlık izni değildir

Geri dönüş rotası eklemek alt ağınıza yanıtların nereye gitmesi gerektiğini söyler. Dokuya, bu paketleri ileten örneğin bunları yabancı bir kaynakla gönderme hakkı olduğunu söylemez. AWS'de ilgili kontrol kaynak ve hedef denetimidir ve her örnek için görünür:

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

Bunu yalnızca belgelenmiş işi iletme olan örnek için kapatın, başka hiçbir şey için değil. Denetimi açık bırakan her uygulama VM'i, ödünç alınmış bir kaynakla trafik göndermek için kullanılabilecek bir makine az demektir. Platformunuz AWS değilse, davranışın aynen geçeceğini varsaymak yerine eşdeğer sahtecilik önleme veya izin verilen adres ayarını arayın.

Hızlı bir paket yakalama, soruyu konsolu okumaktan daha hızlı çözer. Yanıtlar çıkıp istemci onları hiç görmezse, uygulama başarısız olmuyordur, doku sahte kaynağı atıyordur.

Çevirinin satın aldığı ve maliyeti

Kaynağı ağ geçidinde yeniden yazmak geri dönüş yolu sorununu ortadan kaldırır. Uygulama, nasıl erişileceğini zaten bildiği tek bir adres görür ve istemci önekinin bulut yönlendirme tablosunda görünmesi hiç gerekmez. Linux'ta kural tek satırdır ve yapabileceğiniz en dar sürümü yazmaya değer:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

Uygulamanın artık ne kaydettiğine dikkat edin: her kullanıcı için 10.40.3.10, her bağlantıda, sonsuza kadar. Bu değer üzerine kurulmuş her adres izin listesi artık tüm uzaktan erişim nüfusuna erişim veriyor ve her olay incelemesi bunun kim olduğunu yanıtlamak için ağ geçidine geri dönmek zorunda.

Çözüm çeviriden vazgeçmek değil, adresin bir kimlik olduğunu varsaymayı bırakmaktır. İstemci kimliğini kimliği doğrulanmış bir alanda taşıyın, ağ geçidinde çevrilmiş demetle birlikte günlüğe kaydedin ve uygulamanın bunun üzerinden birleşmesine izin verin. Birleştirme anahtarı olmadan çeviri, bir ağ sorununu kalıcı bir adli bilişim sorununa dönüştürür.

Aktarıcı farklı bir arayüzdür

Uygulamanın önündeki ters proxy, yönlendirilmiş yol sorusunu tamamen atlar. Proxy kendi arka uç bağlantısını açar, böylece istemci önekinin sanal ağ içinde yönlendirilebilir olması hiç gerekmez ve uygulama kimliği proxy'nin ayarladığı bir başlıkta alabilir.

Bu başlık yalnızca arka uç onu proxy'den kabul edip başka hiçbir yerden kabul etmediğinde güvenilirdir. nginx terimleriyle bu, gelen her şeye inanmak yerine güvenilen eşi açıkça adlandırmak anlamına gelir:

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Arka uca doğrudan ulaşabilen her istemci aynı başlığı sahteleyebilir, bu yüzden arka uç proxy dışında erişilemez olmalıdır. Bu bir güvenlik duvarı gerçeğidir, yapılandırma görüşü değil, ve insanların pasajı kopyalarken atladığı varsayım tam olarak budur.

Aktarıcı ayrıca ne satın aldığınızı da değiştirir. Uygulama düzeyinde bir kimlik ve onu günlüğe kaydetmek için doğal bir yer elde edersiniz; genelliği kaybedersiniz, çünkü her yeni protokol kendi proxy desteğine ihtiyaç duyar. HTTP hizmetleri için bu takas genellikle iyidir ve HTTP olmayan her şey için genellikle hiç mevcut değildir.

Her sınırın ne gördüğünü yazın

Ne seçerseniz seçin, tasarım incelemesi her sıçramada kaynak adresi ve kanıtlanabilir kimliği adlandıran tek bir tabloyla bitmelidir. O olmadan, ilk olay her biri farklı bir istemci tanımlayan üç ekip üretir.

Sonra seçin. Uygulamanın yetkilendirmesi gerçekten istemci adresine bağlıysa ve rotayı üstlenebiliyorsanız kaynağı koruyun. Öyle değilse ve kimliği bant dışında taşıyabiliyorsanız çevirin, ve platforma özgü iletme ayarları için AWS'nin iletici örnekler kılavuzunu kullanın. Hizmet HTTP konuşuyorsa ve kimliğin artık bir adres olmamasını istiyorsanız aktarıcıya başvurun.