OpenVPN performansı: kaç tane eşzamanlı müşteri mümkün?

Birçok OpenVPN istemcisinin bir OpenVPN sunucusuna bağlandığı bir istemci için bir sistem değerlendiriyorum. "Çok" 50000 - 1000000 anlamına gelir.

Neden bunu yapıyorum? İstemciler, her biri sistem sahipleri dsl yönlendiricisinin arkasında oturan gömülü sistemler olarak dağıtılır. Sunucunun istemcilere komut gönderebilmesi gerekir. İlk saf yaklaşımım, istemcilerin bir openvpn ağı üzerinden sunucuya bağlanmasını sağlamak. Bu şekilde, güvenli iletişim tüneli her iki yönde de kullanılabilir.

Bu, tüm istemcilerin her zaman sunucuya bağlı olduğu anlamına gelir. Yıllar içinde özetleyen birçok müşteri var.

Soru şudur: OpenVPN sunucusu belirli sayıda müşteriye ulaşırken patlar mı? Maksimum TCP bağlantı numarası sınırının zaten farkındayım, bu nedenle (ve diğer nedenlerden dolayı) VPN'nin UDP aktarımını kullanması gerekir.

OpenVPN guruları, fikrin nedir?

Daha önce bu kadar büyük bir kurulum yapılmaya çalışıldığından şüpheliyim, bu yüzden denemeye devam edersiniz. 400 istemciye yönelik bir VPN dağıtımına ilişkin bir makale bulabilirim ancak metne bakarsak, yazar sadece CPU başına kaç müşterinin çalıştırılabileceğine dair kaba tahminlere dayandı ve kurulumunun nasıl bir performans göstereceği konusunda bir anlayışa sahip değildi.

Esas olarak bu iki noktayı göz önünde bulundurmanız gerekir:

1. Veri aktarımlarınızın kullanacağı bant genişliğinin VPN sunucusu tarafında şifreleme / şifre çözme gerektirmesi ve CPU kaynaklarını tüketmesi gerekir

2. OpenVPN istemci bağlantıları, veri aktarılmasa bile sunucudaki hem bellek hem de CPU kaynaklarını kullanır

Günümüzde mevcut olan herhangi bir iyi PC donanımı, Blowfish veya AES-128 ile Gigabit bağlantısını kolayca doyurmalıdır, hatta 100 dolarlık gömülü cihazlar bile 100 Mbps'ye yakın hızlara sahiptir , bu nedenle bant genişliği yoğunluğundan dolayı CPU darboğazları endişelenmemelidir.

3600 saniyelik varsayılan yeniden anahtarlama aralığı göz önüne alındığında, 1.000.000 müşteriden oluşan bir sayı, sunucunun saniyede ortalama 278 anahtar değişimini tamamlayabilmesi gerektiği anlamına gelir. Bir anahtar değişimi oldukça CPU-yoğun bir görev olsa da, gerektiğinde özel donanıma boşaltabilirsiniz - mevcut kriptografik hızlandırıcı kartlar kolayca bu sayıdaki TLS anlaşmalarını karşılar ve aşar. Bellek kısıtlamaları da çok fazla rahatsız etmemelidir - 64 bitlik bir ikili, aksi takdirde vurmanız muhtemel olan sanal bellek kısıtlamalarıyla ilgilenmelidir.

Ancak OpenVPN'in gerçek güzelliği, kolayca ölçeklendirebilmenizdir - rastgele bir sayıda OpenVPN sunucusu kurun ve müşterilerinizin bunları kullandığından emin olun (örn. DNS round-robin aracılığıyla), seçtiğiniz dinamik bir yönlendirme protokolü yapılandırın (genellikle bu basitliği nedeniyle RIP olacaktır) ve altyapınız, yeterli donanıma sahip olduğunuz sürece istediğiniz sayıda müşteriyi destekleyebilecek nitelikte olacaktır.

Bunu, DSL yönlendiricilerin arkasındaki benzer şekilde birkaç yüz uzak bağlantıyla "sadece" olsa da yaptım. Yeniden anahtarlama sorunları hakkında çok fazla yorum yapamam, ancak bu arada öğrendiğim birkaç pratik şey:

1) İstemcileri dağıtırken, istemcide birden fazla VPN sunucusu belirttiğinizden emin olun, vpn1.example.com, vpn2.example.com, vpn3 ..... Şimdi bunlardan yalnızca bir veya ikisini verseniz bile, kendin kafa boşluğu. Doğru şekilde yapılandırılmış olan istemciler, işe yarayan bir tane bulana kadar onları tekrar denemeye devam edecektir.

2) Özel bir AWS VPN sunucusu görüntüsü kullanıyoruz ve isteğe bağlı olarak ilave kapasite artırabiliriz ve Amazon DNS (R53) şeylerin DNS tarafını işler. Altyapımızın geri kalanından tamamen ayrıldı.

3) Sunucuların sonunda, potansiyel istemci sayısını sınırlamak için ağ maskesini dikkatli kullanın. Bu, istemcileri alternatif bir sunucuya zorlamalı ve CPU sorunlarını hafifletmelidir. Sanırım sunucularımızı 300 kadar müşteri ile sınırlandırıyoruz. Bu seçim bizim tarafımızdan biraz keyfi yaptı - istersen "içgüdü hissi".

4) Ayrıca sunucu sonunda güvenlik duvarlarını dikkatli kullanmalısınız. Basit bir ifadeyle, istemciler VPN'in bağlanabileceği şekilde yapılandırılmış durumdayız, ancak sunucular bilinen bir IP adresi dışındaki tüm ssh bağlantılarına kesinlikle izin vermiyor. Müşterilerimize SSH yapabiliriz, zaman zaman ihtiyacımız olursa bize SSH yapamazlar.

5) Müşteri sonunda sizin için yeniden bağlantı kurarak OpenVPN'e güvenmeyin. 10 üzerinden 9 kez olacak, ama bazen sıkışmış olur. OpenVPN'i müşteri ucunda düzenli olarak sıfırlamak / yeniden başlatmak için ayrı bir işlem yapın.

6) Müşteriler için benzersiz anahtarlar üretmenin bir yolunu bulmanız gerekir, böylece bazen onları reddedebilirsiniz. Bunları dahili olarak sunucu oluşturma (PXEboot) işlemimizle üretiyoruz. Başımıza hiç gelmedi, ama yapabileceğimizi biliyoruz.

7) VPN sunucusu bağlantılarınızı etkin bir şekilde izlemek için bazı yönetim araçlarına ve komut dosyalarına ihtiyacınız olacaktır.

Ne yazık ki bunun nasıl yapılacağı hakkında çok fazla malzeme yok, ancak dikkatli bir şekilde yapılandırılması mümkün.

2018 Güncellemesi

2012'den beri nelerin değiştiğinden emin değilim. Sadece 2018'deki deneyimlerime ilişkin bir güncelleme yapmak istedim. OP kurulumuna çok benzeyen bir openvpn ağı kurduk. Uç noktalarımız gömülü cihazlar yerine tam şişmiş linux parçalardır. Her uç noktanın, o site için bilgi ve alarmı görüntülemek için kullanılan bir monitörü vardır ve sunucumuz tüm uç noktalara uzaktan geçmemize izin verir. Ağ aşırı aktif değil ancak bazen aynı anda 5-10 uzak oturum var.

Tek bir çekirdekli ve 2 gb ram içeren masmavi bir görüntüde yaklaşık 100 istemcide güncel bir openvpn yapısı kullanarak, ortalama olarak belleğin yaklaşık% 0,7'sini ve işlemci kullanımı neredeyse her zaman yaklaşık% 0'dır. Bu daha küçük test için bulduğum şeye dayanarak, yeterli teknik özelliklere sahip tek bir sunucunun, eğer desteklemesi için ram olsa, kolayca 50000 eşzamanlı olarak halledeceğini düşündüm. Eğer ram kullanımı doğrusal olarak ölçeklendirilirse, 16 gb, 50000 kullanıcısını, özel bir openvpn makinesinde yeterince fazladan kullanabilecektir.

Önemli bir güvenle şunu söylemek için yeterince büyük değiliz, ancak ağımızı ilk konuşlandırırken bunu bulduğumdan ve bu ölçekte çok daha fazla kaynak kullanımı beklediğimden yeni bir güncelleme yapmak istedim. Şimdi, bunu çalıştıran işlemci donanım şifrelemesine sahip olduğuna inanıyorum ve trafiğin hangi noktada aşırı yükleneceği konusunda emin değilim ama çok fazla iletişim kurmayan uç noktalar için bu bir sorun olmamalıdır.

1000000'de, tek bir makinede 200gb ram'a ihtiyacınız olacak (eğer ekstra olarak ölçeklendirilmişse) bu mümkün olsa bile, bu noktada, her biri 64 gb ram'lı 5 makineye sahip olmak isteyeceğinizi ve böylece tek bir noktaya sahip olmayacağınızı düşünürdüm. başarısızlığın. Bu, önemli sorun yaşamadan 1 veya hatta 2 makinenin bakımını, yeniden başlatılmasını ve değiştirilmesini sağlamalıdır.

Benim ram tahminlerim, tüm openvpn kullanımını, bu ramın yalnızca bir kısmının müşterilerden kaynaklandığı müşterilerin sayısına böldüğümden dolayı büyük olasılıkla fazlaca tahmin ediliyor.

İlk konuşlandırıldığından beri bir yıl içinde 74 uç nokta ekledik. Bu sayıyı önemli ölçüde artırmaya devam etmeyi umuyorum ve makul bir ölçek elde edersek daha fazla güncelleme yapacağız.

Benzer bir problemi araştırıyorum, ancak müşteri sayısı yüzlerce, belki birkaç bin olacak.

Tüm müşterileri her zaman bağlı tutamayacağımı düşündüm.

Müşteriler üzerinde OpenVPN arka planını rasgele zaman aralıklarında başlatmayı düşünüyorum, böylece yoklama yapılıp yapılmadıklarını kontrol edebilirler. Eğer onlar çevrimiçi bir e-posta ya da çevrimiçi olduklarını ve bir süre canlı tutma paketlerini gönderdikleri için onlara bağlanabilsinlerdi.

Bir süre trafik olmazsa daemon arka plan durdurulur.

Şu an karşılaştığım sorun şu anda bağlı olan VPN istemcilerinin listesini almak imkansız görünüyor.