OpenVPN 성능 : 몇 개의 동시 클라이언트가 가능합니까?

많은 OpenVPN 클라이언트가 OpenVPN 서버에 연결되는 클라이언트의 시스템을 평가하고 있습니다. "많은"은 50000-1000000을 의미합니다.

왜 그렇게합니까? 클라이언트는 임베디드 시스템으로 분산되어 있으며 각각 시스템 소유자 dsl 라우터 뒤에 있습니다. 서버는 클라이언트에게 명령을 보낼 수 있어야합니다. 첫 번째 순진한 접근 방식은 클라이언트가 openvpn 네트워크를 통해 서버에 연결하도록하는 것입니다. 이러한 방식으로, 보안 통신 터널은 양방향으로 사용될 수있다.

이는 모든 클라이언트가 항상 서버에 연결되어 있음을 의미합니다. 수년에 걸쳐 많은 고객들이 요약되어 있습니다.

문제는 OpenVPN 서버가 특정 수의 클라이언트에 도달 할 때 폭발합니까? 이미 최대 TCP 연결 수 제한을 알고 있으므로 VPN은 UDP 전송을 사용해야합니다.

OpenVPN 전문가 여러분의 의견은 무엇입니까?

이전에 큰 설정을 시도한 적이 있으므로 의심 할 여지가 있습니다. 400 명의 클라이언트를위한 VPN 배포 에 관한 기사를 찾을 수 있지만 텍스트로 판단했을 때 저자는 CPU 당 얼마나 많은 클라이언트를 실행할 수 있는지에 대한 대략적인 추정에 의존했으며 그의 설정이 어떻게 수행되는지에 대한 이해가 부족했습니다.

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

1. 데이터 전송에 사용할 대역폭은 VPN 서버 측에서 암호화 / 암호 해독이 필요하며 CPU 리소스를 소비합니다.

2. OpenVPN 클라이언트 연결은 데이터가 전송되지 않은 경우에도 서버의 메모리와 CPU 리소스를 모두 소비합니다

오늘날 사용 가능한 적절한 PC 하드웨어는 Blowfish 또는 AES-128을 사용하여 기가비트 링크를 쉽게 포화 시킬 수 있으며, 100 달러에 달하는 내장 장치도 100Mbps 근처의 속도를 지원할 수 있으므로 대역폭 강도로 인한 CPU 병목 현상은 걱정할 필요가 없습니다.

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

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

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

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

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 서버 연결을 효과적으로 모니터링하려면 몇 가지 관리 도구, 스크립트가 필요합니다.

불행히도이 작업을 수행하는 방법에 대한 자료는 많지 않지만 신중하게 구성하면 가능합니다.

2018 업데이트

2012 년 이후의 모든 변화가 무엇인지 잘 모르겠습니다. 2018 년의 경험을 업데이트하고 싶었습니다. OP 설정과 매우 유사한 openvpn 네트워크를 구축했습니다. 우리의 엔드 포인트는 임베디드 장치 대신 완전한 Linux PC입니다. 각 엔드 포인트에는 해당 사이트에 대한 정보 및 경보를 표시하는 데 사용되는 모니터가 있으며 서버는 단일 포인트가 모든 엔드 포인트에 원격으로 연결되도록합니다. 네트워크가 과도하게 활성화되지 않았지만 때때로 5-10 개의 원격 세션이 동시에 있습니다.

단일 코어와 2GB의 램이있는 푸른 이미지에서 약 100 개의 클라이언트에서 현재 openvpn 빌드를 사용하면 평균 약 0.7 %의 메모리를 사용하며 CPU 사용량은 거의 항상 0 %입니다. 이 작은 테스트에서 찾은 것을 기반으로 적절한 사양의 단일 서버가 50000을 지원하는 램이 있으면 동시 처리가 쉽다는 것을 알았습니다. 램 사용량이 선형으로 확장되면 16gb는 전용 openvpn 시스템에서 충분한 여분으로 50000 명의 사용자를 처리 할 수 ​​있습니다.

우리는 상당한 확신을 가지고 충분히 확신 할 수는 없지만 원래 네트워크를 배포 할 때 이것을 발견하고이 규모에서 훨씬 더 많은 리소스 사용을 기대 한 이후 최근 업데이트를 제공하고 싶었습니다. 이제는 이것을 실행하는 CPU에 하드웨어 암호화가 있다고 생각하며 트래픽에 과부하가 걸리는 지점이 확실하지 않지만 많은 통신을하지 않는 엔드 포인트의 경우 문제가되지 않습니다.

1000000에서는 단일 머신에 200GB의 램이 필요합니다 (추가로 선형으로 스케일링 된 경우).이 시점에서 64GB 램이있는 5 대의 머신을 원하므로 단일 포인트가 없어야한다고 생각합니다. 실패. 따라서 중요한 문제없이 1 대 또는 2 대의 기계를 유지 보수, 재시작 및 교체 할 수 있습니다.

내 RAM 추정치는 전체 openvpn 사용량을 클라이언트로 인한 램의 일부만 사용하는 클라이언트 수로 나눠서 과도하게 사용됩니다.

초기 배포 이후 1 년 동안 74 개의 엔드 포인트를 추가했습니다. 나는 그 숫자를 계속해서 증가시키고 우리가 적절한 규모에 도달하면 더 업데이트 할 것입니다.

나는 비슷한 문제를 조사하고 있지만 클라이언트의 수는 수백 명에 달할 것입니다.

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

무작위 시간 간격으로 클라이언트에서 OpenVPN 데몬을 시작하여 폴링되었는지 확인할 수 있습니다. 그들이 전자 메일이나 온라인에있는 것을 보내거나 일정 기간 동안 살아있는 패킷을 보내면 연결할 수 있습니다.

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

지금 당면한 문제는 현재 연결된 VPN 클라이언트 목록을 얻는 것이 불가능하다는 것입니다 ...