Hiệu suất OpenVPN: có bao nhiêu khách hàng đồng thời có thể?

Tôi đang đánh giá một hệ thống cho một máy khách có nhiều máy khách OpenVPN kết nối với máy chủ OpenVPN. "Nhiều" có nghĩa là 50000 - 1000000.

Tại sao tôi làm điều đó? Các máy khách được phân phối các hệ thống nhúng, mỗi hệ thống ngồi phía sau bộ định tuyến dsl của chủ sở hữu hệ thống. Máy chủ cần có khả năng gửi lệnh cho khách hàng. Cách tiếp cận ngây thơ đầu tiên của tôi là làm cho các máy khách kết nối với máy chủ thông qua mạng openvpn. Bằng cách này, đường hầm liên lạc an toàn có thể được sử dụng theo cả hai hướng.

Điều này có nghĩa là tất cả các máy khách luôn được kết nối với máy chủ. Có nhiều khách hàng tổng kết trong những năm qua.

Câu hỏi đặt ra là: máy chủ OpenVPN có phát nổ khi tiếp cận một số lượng khách hàng nhất định không? Tôi đã biết về giới hạn số lượng kết nối TCP tối đa, do đó (và vì các lý do khác) VPN sẽ phải sử dụng truyền tải UDP.

OpenVPN gurus, ý kiến ​​của bạn là gì?

Tôi nghi ngờ rằng một thiết lập lớn đã từng được thử trước đây, vì vậy bạn có thể sẽ bị đẩy giới hạn khi thử. Tôi có thể tìm thấy một bài viết về triển khai VPN cho 400 khách hàng nhưng đánh giá từ văn bản, tác giả chỉ dựa vào ước tính sơ bộ về số lượng máy khách có thể chạy trên mỗi CPU và thiếu hiểu biết về cách thiết lập của anh ta sẽ thực hiện.

Bạn chủ yếu cần phải xem xét hai điểm sau:

1. Băng thông mà dữ liệu bạn chuyển sẽ sử dụng sẽ cần mã hóa / giải mã ở phía máy chủ VPN, tiêu tốn tài nguyên CPU

2. Các kết nối máy khách OpenVPN tiêu thụ cả tài nguyên bộ nhớ và CPU trên máy chủ ngay cả khi không có dữ liệu nào được truyền

Bất kỳ phần cứng PC nào hiện có ngày nay đều dễ dàng bão hòa liên kết Gigabit với Blowfish hoặc AES-128, thậm chí các thiết bị nhúng 100 đô la có khả năng tốc độ gần 100 Mbps , do đó, tắc nghẽn CPU do cường độ băng thông không phải là vấn đề đáng lo ngại.

Với khoảng thời gian gõ lại mặc định là 3600 giây, trung bình 1.000.000 khách hàng có nghĩa là máy chủ sẽ cần có thể hoàn thành trung bình 278 trao đổi khóa mỗi giây. Mặc dù trao đổi khóa là một nhiệm vụ khá tốn CPU, bạn có thể giảm tải nó sang phần cứng chuyên dụng nếu cần - thẻ tăng tốc mật mã có sẵn dễ dàng đáp ứng và vượt quá số lần bắt tay TLS này. Và các hạn chế về bộ nhớ cũng không nên bận tâm quá nhiều - nhị phân 64 bit sẽ quan tâm đến bất kỳ hạn chế bộ nhớ ảo nào mà bạn có thể gặp phải nếu không.

Nhưng vẻ đẹp thực sự với OpenVPN là bạn có thể mở rộng quy mô khá dễ dàng - chỉ cần thiết lập một số lượng máy chủ OpenVPN tùy ý và đảm bảo khách hàng của bạn đang sử dụng chúng (ví dụ thông qua DNS round-robin), định cấu hình giao thức định tuyến động theo lựa chọn của bạn (thông thường, đây sẽ là RIP do tính đơn giản của nó) và cơ sở hạ tầng của bạn sẽ có khả năng hỗ trợ số lượng khách hàng tùy ý miễn là bạn có đủ phần cứng.

Tôi thực sự đã làm điều này, mặc dù với "chỉ" vài trăm kết nối từ xa tương tự phía sau bộ định tuyến DSL. Tôi không thể bình luận quá nhiều về các vấn đề rekeying, nhưng một vài điều thực tế tôi đã học được trên đường đi:

1) Khi triển khai ứng dụng khách, hãy đảm bảo bạn chỉ định nhiều máy chủ VPN trong máy khách conf, vpn1.example.com, vpn2.example.com, vpn3 ..... Ngay cả khi bạn chỉ cung cấp một hoặc hai trong số này chính mình. Được cấu hình đúng cách, các máy khách sẽ tiếp tục thử lại chúng một cách ngẫu nhiên cho đến khi chúng tìm thấy một hoạt động.

2) Chúng tôi sử dụng hình ảnh máy chủ AWS VPN tùy chỉnh và có thể tăng thêm dung lượng theo yêu cầu và Amazon DNS (R53) xử lý phía DNS của mọi thứ. Nó hoàn toàn tách rời khỏi phần còn lại của cơ sở hạ tầng của chúng tôi.

3) Ở cuối (các) máy chủ, hãy sử dụng netmask cẩn thận để hạn chế số lượng khách hàng tiềm năng. Điều đó sẽ buộc các máy khách vào một máy chủ thay thế, giảm thiểu các vấn đề về CPU. Tôi nghĩ rằng chúng tôi giới hạn máy chủ của chúng tôi đến 300 khách hàng. Sự lựa chọn này có phần tùy ý từ phía chúng tôi - "cảm giác ruột" nếu bạn thích.

4) Cũng ở cuối máy chủ, bạn nên sử dụng tường lửa cẩn thận. Nói một cách đơn giản, chúng tôi đã cấu hình chúng tôi để khách hàng có thể kết nối VPN, nhưng các máy chủ không cho phép nghiêm ngặt tất cả các kết nối ssh gửi đến ngoại trừ từ một địa chỉ IP đã biết. Chúng tôi có thể SSH cho khách hàng nếu thỉnh thoảng chúng tôi cần, họ không thể SSH cho chúng tôi.

5) Đừng dựa vào OpenVPN khi thực hiện kết nối lại cho bạn ở cuối máy khách. 9 lần trong số 10 lần, nhưng đôi khi nó bị kẹt. Có một quy trình riêng để thiết lập lại / khởi động lại openVPN ở đầu máy khách thường xuyên.

6) Bạn cần một cách tạo khóa duy nhất cho khách hàng để đôi khi bạn có thể từ chối chúng. Chúng tôi tạo ra những thứ này trong nội bộ với quy trình xây dựng máy chủ (PXEboot) của chúng tôi. Không bao giờ xảy ra với chúng tôi, nhưng chúng tôi biết chúng tôi có thể làm điều đó.

7) Bạn sẽ cần một số công cụ quản lý, tập lệnh để giám sát các kết nối máy chủ VPN của bạn một cách hiệu quả.

Không có nhiều tài liệu về cách làm điều này không may, nhưng có thể, với cấu hình cẩn thận.

Cập nhật 2018

Không chắc chắn tất cả những gì đã thay đổi kể từ năm 2012. Chỉ muốn cập nhật theo kinh nghiệm của tôi vào năm 2018. Chúng tôi đã triển khai một mạng openvpn rất giống với thiết lập OP. Điểm cuối của chúng tôi là các máy linux đầy đủ thay vì các thiết bị nhúng. Mỗi điểm cuối có một màn hình được sử dụng để hiển thị thông tin và báo động cho trang web đó và máy chủ của chúng tôi cho phép chúng tôi một điểm duy nhất để điều khiển từ xa vào tất cả các điểm cuối. Mạng không hoạt động quá mức nhưng đôi khi có 5-10 phiên từ xa cùng một lúc.

Sử dụng bản dựng openvpn hiện tại với khoảng 100 khách hàng trên một hình ảnh màu xanh lam với lõi đơn và 2gb ram, chúng tôi sử dụng trung bình khoảng 0,7% bộ nhớ và mức sử dụng cpu hầu như luôn ở mức 0%. Dựa trên những gì tôi tìm thấy cho thử nghiệm nhỏ hơn này, tôi cho rằng một máy chủ duy nhất có thông số kỹ thuật tốt sẽ dễ dàng xử lý 50000 đồng thời nếu nó có ram để hỗ trợ. Nếu việc sử dụng ram được chia tỷ lệ tuyến tính thì 16gb sẽ có thể xử lý 50000 người dùng với đủ phụ trên một máy openvpn chuyên dụng.

Chúng tôi không ở quy mô đủ lớn để nói rằng với sự tự tin đáng kể nhưng tôi chỉ muốn đưa ra một bản cập nhật gần đây kể từ khi triển khai mạng của chúng tôi, tôi đã tìm thấy điều này và đang mong đợi sử dụng nhiều tài nguyên hơn ở quy mô này. Bây giờ, tôi tin rằng cpu chạy cái này có mã hóa phần cứng và tôi không chắc tại điểm nào sẽ bị quá tải lưu lượng thông minh nhưng đối với các điểm cuối không giao tiếp nhiều thì đây không phải là vấn đề.

Ở mức 1000000, bạn sẽ cần 200gb ram trên một máy duy nhất (nếu được chia tỷ lệ tuyến tính với phụ) trong khi điều này có thể tôi nghĩ rằng tại thời điểm đó bạn sẽ muốn có 5 máy mỗi ram với 64gb ram để bạn không có một điểm duy nhất của sự thất bại. Điều này sẽ cho phép bảo trì, khởi động lại và thay thế 1 hoặc thậm chí 2 máy mà không gặp sự cố đáng kể nào.

Ước tính ram của tôi có thể quá mức cần thiết vì tôi chia toàn bộ việc sử dụng openvpn cho số lượng khách hàng trong đó chỉ một phần của ram đó là do khách hàng.

Chúng tôi đã thêm 74 điểm cuối trong một năm kể từ khi triển khai ban đầu. Tôi hy vọng sẽ tiếp tục tăng con số đó một cách đáng kể và sẽ cập nhật thêm nếu chúng ta đạt được quy mô tốt.

Tôi đang xem xét một vấn đề tương tự, mặc dù số lượng khách hàng sẽ lên tới hàng trăm có thể vài nghìn.

Tôi hình dung rằng tôi không thể giữ tất cả các khách hàng kết nối mọi lúc.

Tôi đang nghĩ đến việc bắt đầu trình nền OpenVPN trên các máy khách theo các khoảng thời gian ngẫu nhiên để họ có thể kiểm tra xem chúng có được bỏ phiếu hay không. Nếu họ là họ sẽ gửi một email hoặc một cái gì đó mà họ đang trực tuyến và gửi các gói tin còn sống trong một khoảng thời gian để tôi có thể kết nối với họ.

Nếu không có lưu lượng truy cập trong một thời gian, daemon sẽ bị dừng.

Vấn đề tôi gặp phải bây giờ là dường như không thể có được danh sách các máy khách VPN hiện đang được kết nối ...