OpenVPN 성능: 동시 클라이언트 수는 몇 개입니까?

Question 1

이전에 이렇게 큰 설정을 시도한 적이 있는지 의심스럽기 때문에 시도할 때 한계를 뛰어 넘을 가능성이 높습니다. 나는에 대한 기사를 찾을 수 있었다400개 클라이언트를 위한 VPN 배포그러나 텍스트를 보면 작성자는 CPU당 실행할 수 있는 클라이언트 수에 대한 대략적인 추정에만 의존했으며 설정이 어떻게 수행되는지에 대한 이해가 부족했습니다.

주로 다음 두 가지 사항을 고려해야 합니다.

데이터 전송에 사용할 대역폭은 VPN 서버 측에서 암호화/암호 해독이 필요하므로 CPU 리소스를 소비합니다.
OpenVPN 클라이언트 연결은 데이터가 전송되지 않는 경우에도 서버의 메모리와 CPU 리소스를 모두 소비합니다.

오늘날 사용 가능한 괜찮은 PC 하드웨어는 Blowfish 또는 AES-128과의 기가비트 링크를 쉽게 포화시킬 것입니다. 심지어 $100 임베디드 장치도 가능합니다.100Mbps에 가까운 속도 가능따라서 대역폭 강도로 인한 CPU 병목 현상은 걱정할 필요가 없습니다.

기본 키 재생성 간격이 3600초인 경우 클라이언트 수가 1,000,000개라는 것은 서버가 초당 평균 278개의 키 교환을 완료할 수 있어야 함을 의미합니다. 키 교환은 CPU를 많이 사용하는 작업이지만 필요한 경우 전용 하드웨어로 오프로드할 수 있습니다. 사용 가능한 암호화 가속기 카드는 이 TLS 핸드셰이크 수를 쉽게 충족하거나 초과합니다. 그리고 메모리 제한도 너무 크게 신경쓰지 않아야 합니다. 64비트 바이너리는 그렇지 않으면 발생할 가능성이 있는 모든 가상 메모리 제한을 처리해야 합니다.

그러나 OpenVPN의 진정한 장점은 매우 쉽게 확장할 수 있다는 것입니다. 임의의 수의 OpenVPN 서버를 설정하고 클라이언트가 이를 사용하고 있는지 확인하고(예: DNS 라운드 로빈을 통해) 원하는 동적 라우팅 프로토콜을 구성하기만 하면 됩니다. (일반적으로 단순성으로 인해 RIP가 됩니다.) 하드웨어가 충분하다면 인프라는 임의의 수의 클라이언트를 지원할 수 있습니다.

Answer

이전에 이렇게 큰 설정을 시도한 적이 있는지 의심스럽기 때문에 시도할 때 한계를 뛰어 넘을 가능성이 높습니다. 나는에 대한 기사를 찾을 수 있었다400개 클라이언트를 위한 VPN 배포그러나 텍스트를 보면 작성자는 CPU당 실행할 수 있는 클라이언트 수에 대한 대략적인 추정에만 의존했으며 설정이 어떻게 수행되는지에 대한 이해가 부족했습니다.

주로 다음 두 가지 사항을 고려해야 합니다.

데이터 전송에 사용할 대역폭은 VPN 서버 측에서 암호화/암호 해독이 필요하므로 CPU 리소스를 소비합니다.
OpenVPN 클라이언트 연결은 데이터가 전송되지 않는 경우에도 서버의 메모리와 CPU 리소스를 모두 소비합니다.

오늘날 사용 가능한 괜찮은 PC 하드웨어는 Blowfish 또는 AES-128과의 기가비트 링크를 쉽게 포화시킬 것입니다. 심지어 $100 임베디드 장치도 가능합니다.100Mbps에 가까운 속도 가능따라서 대역폭 강도로 인한 CPU 병목 현상은 걱정할 필요가 없습니다.

기본 키 재생성 간격이 3600초인 경우 클라이언트 수가 1,000,000개라는 것은 서버가 초당 평균 278개의 키 교환을 완료할 수 있어야 함을 의미합니다. 키 교환은 CPU를 많이 사용하는 작업이지만 필요한 경우 전용 하드웨어로 오프로드할 수 있습니다. 사용 가능한 암호화 가속기 카드는 이 TLS 핸드셰이크 수를 쉽게 충족하거나 초과합니다. 그리고 메모리 제한도 너무 크게 신경쓰지 않아야 합니다. 64비트 바이너리는 그렇지 않으면 발생할 가능성이 있는 모든 가상 메모리 제한을 처리해야 합니다.

그러나 OpenVPN의 진정한 장점은 매우 쉽게 확장할 수 있다는 것입니다. 임의의 수의 OpenVPN 서버를 설정하고 클라이언트가 이를 사용하고 있는지 확인하고(예: DNS 라운드 로빈을 통해) 원하는 동적 라우팅 프로토콜을 구성하기만 하면 됩니다. (일반적으로 단순성으로 인해 RIP가 됩니다.) 하드웨어가 충분하다면 인프라는 임의의 수의 클라이언트를 지원할 수 있습니다.

Question 2

나는 실제로 DSL 라우터 뒤에 있는 수백 개의 원격 연결을 "단지" 사용했지만 실제로 이 작업을 수행했습니다. 키 재생성 문제에 대해 너무 많이 언급할 수는 없지만 그 과정에서 배운 몇 가지 실용적인 사항은 다음과 같습니다.

1) 클라이언트를 배포할 때 클라이언트 conf에 여러 VPN 서버를 지정해야 합니다. vpn1.example.com, vpn2.example.com, vpn3..... 지금은 이 중 하나 또는 두 개만 제공하더라도 너 자신의 헤드룸. 올바르게 구성되면 클라이언트는 작동하는 것을 찾을 때까지 무작위로 계속 재시도합니다.

2) 우리는 사용자 지정 AWS VPN 서버 이미지를 사용하고 필요에 따라 추가 용량을 늘릴 수 있으며 Amazon DNS(R53)가 DNS 측면을 처리합니다. 나머지 인프라와 완전히 분리되어 있습니다.

3) 서버 측에서는 넷마스크를 주의 깊게 사용하여 잠재 클라이언트 수를 제한하십시오. 그러면 클라이언트가 대체 서버로 이동하여 CPU 문제가 완화됩니다. 내 생각엔 우리 서버를 300명 정도의 클라이언트로 제한하는 것 같아요. 이 선택은 우리 측에서는 다소 임의적이었습니다. 원하신다면 "직감"입니다.

4) 서버 측에서도 방화벽을 주의해서 사용해야 합니다. 간단히 말해서 클라이언트가 VPN에 연결할 수 있도록 구성했지만 서버는 알려진 IP 주소를 제외한 모든 SSH 연결 인바운드를 엄격히 허용하지 않습니다. 가끔 필요한 경우 클라이언트에 SSH로 연결할 수 있지만 클라이언트는 우리에게 SSH로 연결할 수 없습니다.

5) 클라이언트 측에서 재연결을 수행하는 OpenVPN에 의존하지 마십시오. 10번 중 9번은 그럴 것이지만 때로는 멈추는 경우도 있습니다. 클라이언트 측에서 정기적으로 openVPN을 재설정/다시 시작하는 별도의 프로세스가 있습니다.

6) 때때로 클라이언트를 거부할 수 있도록 클라이언트에 대한 고유 키를 생성하는 방법이 필요합니다. 서버 빌드(PXEboot) 프로세스를 통해 내부적으로 이를 생성합니다. 우리에게는 그런 일이 일어나지 않았지만 우리는 할 수 있다는 것을 알고 있습니다.

7) VPN 서버 연결을 효과적으로 모니터링하려면 몇 가지 관리 도구와 스크립트가 필요합니다.

안타깝게도 이 작업을 수행하는 방법에 대한 자료는 많지 않지만 주의 깊게 구성하면 가능합니다.

Answer

나는 실제로 DSL 라우터 뒤에 있는 수백 개의 원격 연결을 "단지" 사용했지만 실제로 이 작업을 수행했습니다. 키 재생성 문제에 대해 너무 많이 언급할 수는 없지만 그 과정에서 배운 몇 가지 실용적인 사항은 다음과 같습니다.

1) 클라이언트를 배포할 때 클라이언트 conf에 여러 VPN 서버를 지정해야 합니다. vpn1.example.com, vpn2.example.com, vpn3..... 지금은 이 중 하나 또는 두 개만 제공하더라도 너 자신의 헤드룸. 올바르게 구성되면 클라이언트는 작동하는 것을 찾을 때까지 무작위로 계속 재시도합니다.

2) 우리는 사용자 지정 AWS VPN 서버 이미지를 사용하고 필요에 따라 추가 용량을 늘릴 수 있으며 Amazon DNS(R53)가 DNS 측면을 처리합니다. 나머지 인프라와 완전히 분리되어 있습니다.

3) 서버 측에서는 넷마스크를 주의 깊게 사용하여 잠재 클라이언트 수를 제한하십시오. 그러면 클라이언트가 대체 서버로 이동하여 CPU 문제가 완화됩니다. 내 생각엔 우리 서버를 300명 정도의 클라이언트로 제한하는 것 같아요. 이 선택은 우리 측에서는 다소 임의적이었습니다. 원하신다면 "직감"입니다.

4) 서버 측에서도 방화벽을 주의해서 사용해야 합니다. 간단히 말해서 클라이언트가 VPN에 연결할 수 있도록 구성했지만 서버는 알려진 IP 주소를 제외한 모든 SSH 연결 인바운드를 엄격히 허용하지 않습니다. 가끔 필요한 경우 클라이언트에 SSH로 연결할 수 있지만 클라이언트는 우리에게 SSH로 연결할 수 없습니다.

5) 클라이언트 측에서 재연결을 수행하는 OpenVPN에 의존하지 마십시오. 10번 중 9번은 그럴 것이지만 때로는 멈추는 경우도 있습니다. 클라이언트 측에서 정기적으로 openVPN을 재설정/다시 시작하는 별도의 프로세스가 있습니다.

6) 때때로 클라이언트를 거부할 수 있도록 클라이언트에 대한 고유 키를 생성하는 방법이 필요합니다. 서버 빌드(PXEboot) 프로세스를 통해 내부적으로 이를 생성합니다. 우리에게는 그런 일이 일어나지 않았지만 우리는 할 수 있다는 것을 알고 있습니다.

7) VPN 서버 연결을 효과적으로 모니터링하려면 몇 가지 관리 도구와 스크립트가 필요합니다.

안타깝게도 이 작업을 수행하는 방법에 대한 자료는 많지 않지만 주의 깊게 구성하면 가능합니다.

Question 3

2018년 업데이트

2012년 이후 모든 것이 어떻게 변경되었는지 잘 모르겠습니다. 2018년 내 경험에 대한 업데이트를 제공하고 싶었습니다. 우리는 OP 설정과 매우 유사한 openvpn 네트워크를 배포했습니다. 우리의 엔드포인트는 임베디드 장치가 아닌 완전한 Linux PC입니다. 각 엔드포인트에는 해당 사이트에 대한 정보와 경보를 표시하는 데 사용되는 모니터가 있으며 당사 서버를 통해 단일 지점에서 모든 엔드포인트에 원격으로 연결할 수 있습니다. 네트워크가 과도하게 활성화되지는 않지만 때로는 5-10개의 원격 세션이 동시에 발생하는 경우도 있습니다.

단일 코어와 2GB RAM이 있는 Azure 이미지의 약 100개 클라이언트에서 현재 openvpn 빌드를 사용하면 평균 약 0.7%의 메모리를 사용하고 CPU 사용량은 거의 항상 약 0%입니다. 이 소규모 테스트에서 찾은 내용을 토대로 적절한 사양을 갖춘 단일 서버가 이를 지원하는 램이 있다면 쉽게 50000 동시 처리를 처리할 수 있을 것이라고 생각합니다. RAM 사용량이 선형적으로 확장되면 16GB는 전용 openvpn 시스템에서 충분한 추가 비용으로 50,000명의 사용자를 처리할 수 있습니다.

우리는 상당한 자신감을 가지고 말할 만큼 규모가 크지는 않지만 처음에 네트워크를 배포할 때 이것을 발견했고 이 규모에서 훨씬 더 많은 리소스 사용량을 기대했기 때문에 최근 업데이트를 제공하고 싶었습니다. 이제 나는 이것을 실행하는 CPU에 하드웨어 암호화가 있다고 믿으며 어느 시점에서 트래픽이 과부하될지는 잘 모르겠지만 많이 통신하지 않는 엔드포인트의 경우 이는 문제가 되지 않습니다.

1000000에서는 단일 머신에 200GB의 RAM이 필요하지만(추가로 선형적으로 확장된 경우) 이것이 가능하지만 그 시점에서는 각각 64GB의 RAM이 있는 5개의 머신을 갖고 싶어하므로 단일 지점이 없을 것이라고 생각합니다. 실패의. 이를 통해 심각한 문제 없이 1개 또는 2개의 시스템을 유지 관리, 다시 시작 및 교체할 수 있습니다.

전체 openvpn 사용량을 해당 램의 일부만 클라이언트로 인한 클라이언트 수로 나누기 때문에 내 램 추정치는 너무 과도할 수 있습니다.

처음 배포한 이후 1년 만에 엔드포인트 74개를 추가했습니다. 저는 그 숫자를 계속해서 크게 늘리기를 희망하며, 적절한 규모에 도달하면 추가 업데이트를 실시할 것입니다.

Answer

2018년 업데이트

2012년 이후 모든 것이 어떻게 변경되었는지 잘 모르겠습니다. 2018년 내 경험에 대한 업데이트를 제공하고 싶었습니다. 우리는 OP 설정과 매우 유사한 openvpn 네트워크를 배포했습니다. 우리의 엔드포인트는 임베디드 장치가 아닌 완전한 Linux PC입니다. 각 엔드포인트에는 해당 사이트에 대한 정보와 경보를 표시하는 데 사용되는 모니터가 있으며 당사 서버를 통해 단일 지점에서 모든 엔드포인트에 원격으로 연결할 수 있습니다. 네트워크가 과도하게 활성화되지는 않지만 때로는 5-10개의 원격 세션이 동시에 발생하는 경우도 있습니다.

단일 코어와 2GB RAM이 있는 Azure 이미지의 약 100개 클라이언트에서 현재 openvpn 빌드를 사용하면 평균 약 0.7%의 메모리를 사용하고 CPU 사용량은 거의 항상 약 0%입니다. 이 소규모 테스트에서 찾은 내용을 토대로 적절한 사양을 갖춘 단일 서버가 이를 지원하는 램이 있다면 쉽게 50000 동시 처리를 처리할 수 있을 것이라고 생각합니다. RAM 사용량이 선형적으로 확장되면 16GB는 전용 openvpn 시스템에서 충분한 추가 비용으로 50,000명의 사용자를 처리할 수 있습니다.

우리는 상당한 자신감을 가지고 말할 만큼 규모가 크지는 않지만 처음에 네트워크를 배포할 때 이것을 발견했고 이 규모에서 훨씬 더 많은 리소스 사용량을 기대했기 때문에 최근 업데이트를 제공하고 싶었습니다. 이제 나는 이것을 실행하는 CPU에 하드웨어 암호화가 있다고 믿으며 어느 시점에서 트래픽이 과부하될지는 잘 모르겠지만 많이 통신하지 않는 엔드포인트의 경우 이는 문제가 되지 않습니다.

1000000에서는 단일 머신에 200GB의 RAM이 필요하지만(추가로 선형적으로 확장된 경우) 이것이 가능하지만 그 시점에서는 각각 64GB의 RAM이 있는 5개의 머신을 갖고 싶어하므로 단일 지점이 없을 것이라고 생각합니다. 실패의. 이를 통해 심각한 문제 없이 1개 또는 2개의 시스템을 유지 관리, 다시 시작 및 교체할 수 있습니다.

전체 openvpn 사용량을 해당 램의 일부만 클라이언트로 인한 클라이언트 수로 나누기 때문에 내 램 추정치는 너무 과도할 수 있습니다.

처음 배포한 이후 1년 만에 엔드포인트 74개를 추가했습니다. 저는 그 숫자를 계속해서 크게 늘리기를 희망하며, 적절한 규모에 도달하면 추가 업데이트를 실시할 것입니다.

Question 4

비슷한 문제를 조사 중입니다. 클라이언트 수가 수백, 어쩌면 수천에 달할 수도 있습니다.

나는 모든 클라이언트를 항상 연결 상태로 유지할 수는 없다고 생각했습니다.

클라이언트에서 무작위 시간 간격으로 OpenVPN 데몬을 시작하여 클라이언트가 폴링되었는지 확인할 수 있도록 할 생각입니다. 만약 그렇다면 그들은 온라인에 있는 이메일이나 무언가를 보내고 내가 그들에게 연결할 수 있도록 일정 기간 동안 연결 유지 패킷을 보내야 합니다.

일정 시간 동안 트래픽이 없으면 데몬이 중지됩니다.

지금 제가 겪고 있는 문제는 현재 연결된 VPN 클라이언트 목록을 가져오는 것이 불가능해 보인다는 것입니다...

Answer