Le performance OpenVPN sono terribili per altre macchine sulla subnet del server

Sto utilizzando un "server" che è una hacker-up di prima generazione di Apple TV che esegue Linux.

Ho molte difficoltà a get le performance di OpenVPN per essere quello che mi aspetterei con la mia nuova configuration OpenVPN. La networking sembra così:

Home LAN 172.16.1.0/24 Clienti VPN (10.8.0.0/24) -> Aeroporto Extreme (inoltro port OpenVPN) -> OpenVPN Server (ascolto sulla port OpenVPN 1294) -> Home iMac -> NAS Box

Sto usando il routing, con il seguente file di configuration. Il routing è impostato utilizzando IP Masquerading sul server OpenVPN, perché non posso creare routes statici sul mio gateway, che è un aeroporto estremo). Si noti che l'utilizzo della CPU sul server VPN è minimo in tutti i test riportti di seguito.

Configurazione del server:

port 1294 proto udp dev tun ca privnet/ca.crt cert privnet/server.crt key privnet/server.key dh privnet/dh2048.pem server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt keepalive 10 120 comp-lzo user nobody group nobody persist-key persist-tun status openvpn-status.log verb 4 script-security 2 push "route 172.16.1.0 255.255.255.0" topology subnet route 192.168.163.0 255.255.255.0 10.8.0.2 tun-mtu 1500 fragment 1000 mssfix 

I test in esecuzione utilizzano solo un client VPN. Senza le linee di frammento e mssfix sia nel client che nel server config, le performance erano così male che ho un frame VNC o così al secondo quando VPNing su due 35Mb FiOS connessioni. Quando ho aggiunto queste righe, le performance VPN migliorate ma sono ancora molto lente.

Il mio caso di prova è anche la prestazione SCP.

  • Il download di client tramite SCP forma il server OpenVPN senza VPN è veloce (1 MBps).
  • Il download di client tramite SCP dal server OpenVPN con VPN triggersto (utilizzando i server VPN locale LAN IP e port) è veloce (1 MBps)
  • Il download di client tramite SCP da qualsiasi altro computer della subnet del server OpenVPN con VPN triggersto è estremamente lento (<50 KBps).
  • Il caricamento del client tramite SCP al server OpenVPN senza VPN è veloce (> 300 KBps)
  • Il caricamento del cliente tramite SCP al server OpenVPN con VPN triggersto è veloce (> 300 KBps)
  • Il caricamento del client tramite SCP a qualsiasi altro computer della subnet del server OpenVPN con VPN triggersto è veloce (> 300 KBps)

Qualcuno può suggerire cosa fare e perché vedo queste velocità molto diverse?

  • Accedi a un host virtuale di un altro computer nella stessa networking
  • Qual è l'indirizzo di networking (xxx0) utilizzato?
  • Reti, sottoreti, routing e NAT
  • Subnetting in 6 network CIDR / 24 e 2 reti CIDR / 27?
  • CIDR per i Dummies
  • come configurare due blocchi IP per l'utilizzo in una networking
  • Struttura di indirizzo IP di base
  • In quali scenari sarebbe una VLAN non allineare 1: 1 con una substring?
  • 4 Solutions collect form web for “Le performance OpenVPN sono terribili per altre macchine sulla subnet del server”

    MTU è in genere il problema di tutte le VPN. Il frammento potrebbe aiutare, ma si potrebbe provare ad abbassare l'MTU su una macchina di prova e fare un test SCP.

    L'altra cosa che si potrebbe guardare è NATing. Fai TCPdump sulle interfacce interne (il traffico non crittografato) e assicuratevi di vedere gli IP che ci si aspetterebbe. Ho visto alcuni NAT misconfigurati e il routing che hanno completamente esaurito le performance.

    Inoltre, una TCPdump ti dirà la dimensione del pacchetto, che è utile per la risoluzione dei problemi.

    Beh, è ​​un colpo al buio: Contrariamente alla saggezza tradizionale , ho avuto una situazione su una connessione facilmente congestionata (ADSL 6 / 0,6Mbit / s) che ha funzionato meglio (dovrei dire solo?) Se il traffico OpenVPN è incapsulato in un Flusso TCP in contrasto con i datagrammi UDP.

    Il problema era che i timeout sul stream TCP interno si sono verificati a causa dei pacchetti UDP abbassati del stream criptato (la congestione è la fonte primaria). In qualche modo la scalatura della window nel canale TCP interno non ha aiutato come previsto (dovrebbe scendere in fondo a un ciclo di invio-waitack).

    Per quanto riguarda la diagnosi: installare wireshark e catturare il traffico openvpn e il traffico LAN e guardare per eccessive trasmissioni TCP. Questi sono segni di pacchetti scesi. Vedi anche se c'è un problema di routing con i pacchetti che appaiono sull'interface sbagliata o con l'IP errato (come notato da JakeRobinson).

    Inoltre cerchi di ridurre tun-mtu a qualcosa di innocente come il 1300. Questo danneggerà la velocità massima, ma non nella regione in cui hai problemi.

    Buona fortuna e farci sapere se scopri la causa!

    Ha capito: era un problema, sia hardware che i driver, con la scheda di networking sul server. Il "server" è un Apple TV di prima generazione in esecuzione in esecuzione Linux, e per qualche motivo l'ethernet incorporato non funzionava molto bene quando faceva mascheramento. Ho collegato un dongle di ethernet gigabit USB, e tutto va bene!

    Se capisco bene la tua configuration, credo, che tu abbia una ctriggers linea nella configuration del server:

     push "route 172.16.1.0 255.255.255.0" 

    Questa linea è la direttiva per il server da submit al client, il path verso la substring 172.16.1.0/24 è tramite un server VPN, che non è giusto, no?

    E, in secondo luogo, penso che tu abbia invece questa linea nella configuration del server questa linea:

     push "route 192.168.163.0 255.255.255.0" 

    perché questa è la networking dietro un server VPN …

    Puoi controllarlo quando si connette al server VPN e elenca i tuoi routes …

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.