Kubernetes içinde VPN istemci IP'si: koruyalım mı yoksa SNAT mı yapalım?
Kubernetes içinde gerçek VPN istemci adresini korumak ile kaynak NAT arasında üç koşula göre seçim yapın, ardından dönüş yolunu ve pod değişimini doğrulayın.
Tünel ile backend arasında bir yerde istemci adresi ya hayatta kalır ya değiştirilir ve iki sonuç da savunulabilir. Seçim, alıcı hizmetin sahibine aittir, CNI'yi kuran kişiye değil. İstemci başına yetkilendirme, kotalar veya denetim kayıtları önemli olduğunda adres her atlama noktasından geçmelidir. Paylaşılan atıf kabul edilebilirse kaynak NAT, aksi halde sonsuza kadar sürdüreceğiniz bir yönlendirme sorununu ortadan kaldırır.
İstemci adresi gerçekte nerede kaybolur
Uzak bir istemcinin paketi VPN pod'una tünel aralığı içinde bir iç kaynakla ulaşır, diyelim ki 10.90.0.42. Pod bu paketi bir ClusterIP veya pod IP'sine doğru ilettiğinde, üç farklı mekanizma kaynağı yeniden yazabilir. Düğümün CNI masquerade kuralı podun küme CIDR'i dışına gönderdiği trafiği kapsar. Hedef düğümdeki kube-proxy conntrack girdisi Service atlamasının kendisini kapsar. Bağlantıyı sonlandıran bir proxy paketi hiç iletmez, bu yüzden sonunda gördüğünüz kaynak proxy'ye aittir.
Her biri farklı bir katmanda yaşar, bu yüzden tek bir Service alanı neredeyse hiçbir zaman tüm yolu onarmaz.
VPN'in genel Service'indeki externalTrafficPolicy yalnızca dış bağlantıya ne olacağına karar verir: Local uzak adresi onu alan düğümde tutar, Cluster ise kube-proxy'nin paketi başka bir düğüme vermesine ve orada masquerade yapmasına izin verir. Bu ayar istemcilerinizin bağlandığı listener'ı yönetir. VPN sürecinizin daha sonra kümeye yönlendirdiği şifresi çözülmüş paket hakkında hiçbir şey söylemez.
Tartışmayı bitiren üç koşul
Bu konu her açıldığında aynı üç soruyu aynı sırayla sorarım, çünkü ilki genellikle tartışmayı bitirir. Bunları kümenin bütünü için değil, belirli iş yükü için yanıtlayın. Aynı şirketteki iki küme farklı yanıtlara varabilir ve ikisi de haklı olabilir.
| Question | Preserve | SNAT |
|---|---|---|
| Does the backend enforce policy per client? | Yes, the address is the identity | Only if a trusted proxy supplies identity |
| Can the cluster route 10.90.0.0/24 back to a stable gateway? | Required | Not needed |
| Is the workload a forwarder or a proxy? | Forwarder | Proxy is fine |
Backend ilk soruya evet, ikincisine hayır derse, düzenlenecek bir manifest değil yapılacak ağ işiniz var demektir. Üçüncü satır proxy diyorsa adres asla hayatta kalmayacaktı ve aksini iddia etmek bir hafta paket yakalamaya mal olur.
preserve modunun ağdan istediği şey
Kaynağı korumak, hedef düğümün trafiği etkin bir VPN ağ geçidi üzerinden 10.90.0.42'ye geri göndermesi gerektiği anlamına gelir. VPN havuzu bir küme CIDR'i değildir, bu yüzden hiçbir CNI onu varsayılan olarak sizin için yönlendirmez. Rotayı kendiniz eklersiniz, sonra işaret ettiği ağ geçidi uç noktasının yeniden planlamadan sağ çıktığından emin olursunuz.
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2Sonraki atlama bir pod adresidir ve pod adresleri yer değiştirir. Rotayı bir Service VIP'sine veya yerinde kalan bir düğüm adresine yönlendirin, ya da her çıkarmadan sonra ağ geçidinin peşinden koşacağınızı kabul edin. Ters yol filtrelemesi diğer tuzaktır: katı mod, dönüş yolu geldikleri arayüzle eşleşmeyen paketleri düşürür ve bu tam olarak korunmuş bir VPN akışının şeklidir.
Gevşek doğrulama çoğu zaman çalışan bir dönüş yolu ile backend'den ayrıldıktan sonra kaybolan yanıtlar arasındaki farktır. VPN düğümündeki masquerade kuralları da tünel aralığını dışlamalıdır, yoksa iletilen paket hangi rotayı kurduğunuzdan bağımsız olarak podun adresiyle çıkar. Bu dışlamayı iptables'ı elle düzenlemek yerine CNI'nin kendi yapılandırmasında ifade etmeyi tercih edin, çünkü ajan yeniden başlatmada zincirlerini yeniden yazar ve elle yazdığınız kural tam olarak bir sonraki yükseltmeye kadar yaşar.
NetworkPolicy erişim denetimidir, yönlendirme değil. Bir politikayı sıkılaştırmak masquerade'ın zaten değiştirdiği bir adresi asla geri getirmez.
SNAT neye mal olur ve nasıl yazılır
Kümeye doğru kaynak NAT daha ucuz tasarımdır ve bu bir hata değildir. Backend VPN podunun veya düğümün adresini görür, günlükler birbirini tutar ve hiçbir dönüş rotasının var olması gerekmez. Kaybettiğiniz şey iki istemciyi ağ katmanında ayırt etme yeteneğidir, bu yüzden kotalar, yasaklar ve denetim izleri başka bir yerden gelmelidir.
Genellikle o başka yer uygulamadır: bir oturum belirteci, imzalı bir başlık veya kontrol ettiğiniz bir proxy'nin yazdığı PROXY protokol satırı. Bunlar alıcıya yalnızca proxy yolda olduğunda ve başlık istemci tarafından ayarlanamadığında güvenebileceği bir kimlik verir. Runbook'ta hangisinin geçerli olduğunu açıkça yazın, çünkü bir sonraki mühendis günlükteki adresin istemci olduğunu varsayacaktır. Değildir ve tek bir olay bu varsayımı pahalı hale getirmeye yeter.
Takas yazıya döküldüğü sürece dürüst kalır.
Çalışan bir yolu şanslı olandan ayıran kontroller
Önbelleğe alınmış bir bağlantı yerine taze bir bağlantıyla test edin ve iki yönde de test edin. Birçok arıza yalnızca yeni akışlar yeniden yazılmış yolu izlediği için aralıklı görünür.
Yetkili tek bir istek sırasında tuple'ı üç noktada yakalayın: kapsülleme çözüldükten hemen sonra, VPN podunun çıkış arayüzünde ve backend'de. Kaynak ikinci ve üçüncü yakalama arasında değişiyorsa neden podun aşağı akışındadır. İkinciden önce değişiyorsa podun kendisi çeviriyor demektir.
Ardından VPN podunu silin ve yeniden planlanırken testi yineleyin. Çıkarmada kırılan korunmuş bir yol tamamlanmamıştır, artık var olmayan bir adrese sabitlenmiş NAT kuralı da öyledir. Son olarak reddedilmesini beklediğiniz bir kaynaktan tek bir istek gönderin ve reddin eksik bir rotadan değil politikadan geldiğini doğrulayın.