Prestazioni OpenVPN: quanti client simultanei sono possibili?

Sto valutando un sistema per un client in cui molti client OpenVPN si connettono a un server OpenVPN. "Molti" significa 50000 - 1000000.

Perché lo faccio? I client sono sistemi embedded distribuiti, ognuno seduto dietro il router dsl dei proprietari di sistema. Il server deve essere in grado di inviare comandi ai client. Il mio primo approccio ingenuo è fare in modo che i client si connettano al server tramite una rete openvpn. In questo modo, il tunnel di comunicazione sicuro può essere utilizzato in entrambe le direzioni.

Ciò significa che tutti i client sono sempre connessi al server. Ci sono molti clienti che riassumono nel corso degli anni.

La domanda è: il server OpenVPN esplode quando raggiunge un certo numero di client? Sono già a conoscenza di un limite massimo del numero di connessione TCP, pertanto (e per altri motivi) la VPN dovrebbe utilizzare il trasporto UDP.

Guru OpenVPN, qual è la tua opinione?

Dubito che una configurazione così grande sia mai stata tentata prima, quindi probabilmente spingerai i limiti quando proverai. Potrei trovare un articolo su una distribuzione VPN per 400 client, ma a giudicare dal testo, l'autore ha fatto solo affidamento su stime approssimative su quanti client potevano essere eseguiti per CPU e mancava una certa comprensione delle prestazioni della sua configurazione.

Dovresti considerare principalmente questi due punti:

1. La larghezza di banda utilizzata dai trasferimenti di dati richiederebbe la crittografia / la decrittografia sul lato del server VPN, consumando risorse della CPU

2. Le connessioni client OpenVPN consumano risorse di memoria e CPU sul server anche quando non vengono trasferiti dati

Qualsiasi hardware per PC decente disponibile oggi dovrebbe facilmente saturare un collegamento Gigabit con Blowfish o AES-128, anche i dispositivi incorporati da $ 100 sono in grado di raggiungere velocità vicine a 100 Mbps , quindi i colli di bottiglia della CPU dovuti all'intensità della larghezza di banda non dovrebbero preoccupare.

Dato l'intervallo di reimpostazione predefinito di 3600 secondi, un numero di 1.000.000 di client significherebbe che il server dovrebbe essere in grado di completare in media 278 scambi di chiavi al secondo. Mentre uno scambio di chiavi è un'attività piuttosto intensiva per la CPU, è possibile scaricarlo su hardware dedicato se necessario - le schede di accelerazione crittografiche disponibili si incontrano facilmente e superano questo numero di handshake TLS. E anche le restrizioni di memoria non dovrebbero disturbare troppo: un binario a 64 bit dovrebbe occuparsi di tutte le restrizioni di memoria virtuale che altrimenti verrebbero colpite.

Ma la vera bellezza di OpenVPN è che puoi ridimensionarlo abbastanza facilmente: devi semplicemente impostare un numero arbitrario di server OpenVPN e assicurarti che i tuoi clienti li stiano usando (ad es. Tramite il round robin DNS), configurare un protocollo di routing dinamico a tua scelta (in genere questo sarebbe RIP per la sua semplicità) e la tua infrastruttura sarebbe in grado di supportare un numero arbitrario di client purché tu abbia abbastanza hardware.

In realtà l'ho fatto, anche se con "solo" alcune centinaia di connessioni remote analogamente dietro router DSL. Non posso commentare troppo i problemi di rekey, ma alcune cose pratiche che ho imparato lungo la strada:

1) Quando si distribuiscono client, assicurarsi di specificare più server VPN nel client conf, vpn1.example.com, vpn2.example.com, vpn3 ..... Anche se si forniscono solo uno o due di questi ora, si dà te stesso headroom. Configurati correttamente, i client continueranno a riprovarli a caso fino a quando non ne troveranno uno che funziona.

2) Utilizziamo un'immagine del server VPN AWS ​​personalizzata e possiamo aumentare la capacità aggiuntiva su richiesta e Amazon DNS (R53) gestisce il lato DNS delle cose. È completamente staccato dal resto della nostra infrastruttura.

3) Sul lato server (s), fare un uso attento della maschera di rete per limitare il numero di potenziali client. Ciò dovrebbe forzare i client su un server alternativo, mitigando i problemi della CPU. Penso che limitiamo i nostri server a circa 300 client. Questa scelta è stata in qualche modo arbitraria da parte nostra: "sentirsi bene" se vuoi.

4) Inoltre, sul lato server, è necessario utilizzare con attenzione i firewall. In termini semplici, abbiamo configurato il nostro in modo tale che i client possano connettersi tramite VPN, ma i server non consentono rigorosamente tutte le connessioni SSH in entrata tranne che da un indirizzo IP noto. Possiamo SSH per i clienti se occasionalmente ne abbiamo bisogno, loro non possono SSH per noi.

5) Non fare affidamento sul fatto che OpenVPN esegua la riconnessione per te alla fine del client. Sarà 9 volte su 10, ma a volte si blocca. Avere un processo separato per reimpostare / riavviare openVPN sul lato client regolarmente.

6) È necessario un modo per generare chiavi univoche per i client in modo da poterle negare a volte. Li generiamo internamente con il nostro processo di build server (PXEboot). Non ci è mai successo, ma sappiamo di poterlo fare.

7) Avrai bisogno di alcuni strumenti di gestione, script per monitorare efficacemente le connessioni del tuo server VPN.

Sfortunatamente non c'è molto materiale su come farlo, ma è possibile, con un'attenta configurazione.

Aggiornamento 2018

Non sono sicuro di cosa sia cambiato tutto dal 2012. Volevo solo dare un aggiornamento sulla mia esperienza nel 2018. Abbiamo implementato una rete openvpn molto simile alla configurazione dell'OP. I nostri endpoint sono pc linux completi invece di dispositivi embedded. Ogni endpoint ha un monitor utilizzato per visualizzare informazioni e allarmi per quel sito e il nostro server ci consente un singolo punto per remotare in tutti gli endpoint. La rete non è eccessivamente attiva ma a volte ha 5-10 sessioni remote contemporaneamente.

Utilizzando una build corrente di openvpn su circa 100 client su un'immagine azzurrata con un singolo core e 2 GB di RAM, utilizziamo in media lo 0,7% circa della memoria e l'utilizzo della CPU è quasi sempre intorno allo 0%. Sulla base di ciò che ho trovato per questo test più piccolo, immagino che un singolo server con specifiche decenti gestirà facilmente 50000 concorrenti se avesse la RAM per supportarlo. Se l'utilizzo del ram si ridimensionasse in modo lineare, allora 16 GB sarebbero in grado di gestire 50000 utenti con abbastanza extra su una macchina openvpn dedicata.

Non siamo su una scala sufficientemente ampia per dirlo con notevole fiducia, ma volevo solo dare un aggiornamento recente poiché quando ho distribuito la nostra rete in origine l'ho trovato e mi aspettavo molto più utilizzo delle risorse su questa scala. Ora, credo che la CPU che esegue questo abbia crittografia hardware e non sono sicuro a che punto sarebbe sovraccarico di traffico, ma per gli endpoint che non comunicano molto questo non dovrebbe essere un problema.

A 1000000 avresti bisogno di 200 GB di RAM su una singola macchina (se ridimensionata in modo lineare con extra) mentre questo è possibile, penso che a quel punto vorrai avere 5 macchine ciascuna con 64 GB di RAM in modo da non avere un singolo punto di fallimento. Ciò dovrebbe consentire la manutenzione, il riavvio e la sostituzione di 1 o anche 2 macchine senza problemi significativi.

Le mie stime di RAM sono probabilmente eccessive poiché sto dividendo l'intero utilizzo di openvpn per numero di client in cui solo una parte di quella RAM è dovuta ai client.

Abbiamo aggiunto 74 endpoint in un anno da quando inizialmente distribuito. Spero di continuare a far crescere quel numero in modo significativo e farò un ulteriore aggiornamento se arriveremo a una scala decente.

Sto esaminando un problema simile, anche se il numero di clienti sarebbe in centinaia forse un paio di migliaia.

Ho pensato che non riuscissi a mantenere tutti i client sempre connessi.

Sto pensando di avviare il demone OpenVPN sui client a intervalli di tempo casuali in modo che possano verificare se sono stati sottoposti a polling. In tal caso, devono inviare un'e-mail o qualcosa in cui si trovano online e inviare pacchetti keep-alive per un certo periodo di tempo, in modo che io possa connettermi ad essi.

Se non c'è traffico per qualche tempo, il demone viene arrestato.

Il problema che sto affrontando in questo momento è che sembra impossibile ottenere un elenco dei client VPN attualmente connessi ...