Como fazer o OpenVPN usar o VIA Padlock no OpenBSD?

2

Comprei um roteador baseado em VIA com o único objetivo de executar o OpenVPN nele. Infelizmente parece que o Padlock não é usado. Aqui está a parte importante do dmesg:

OpenBSD 4.8 (GENERIC) #136: Mon Aug 16 09:06:23 MDT 2010
[email protected]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: VIA C7 Processor 1500MHz ("CentaurHauls" 686-class) 1.51 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,SBF,SSE3,EST,TM2,xTPR

Meu OpenVPN-Config tem essas opções relacionadas às cifras / cadeados:

cipher AES-128-CBC
engine cryptodev

Eu posso verificar se o usercrypto está habilitado pelo benchmarking com o comando openssl speed. O sysctl também lê:

kern.usercrypto=1

Estou a deduzir que o Padlock não é usado a partir destas informações de topo que são tomadas a 40 Mbit / seg (no máximo 70 / seg) através do túnel VPN:

load averages:  0.66,  0.62,  0.54                                                                                                                                                          crypto.b0nd4ge.de 21:03:04
28 processes:  2 running, 25 idle, 1 on processor
CPU states:  1.9% user,  0.0% nice,  2.9% system,  3.2% interrupt, 92.1% idle
Memory: Real: 30M/142M act/tot  Free: 839M  Swap: 0K/1214M used/tot

  PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
20161 root      59    0 1224K 2676K run       -       116:45 53.42% openvpn
11092 named      2    0   18M   19M sleep     select   67:50  0.10% named

O que mais posso fazer para que o Padlock funcione com o OpenVPN? É realmente uma pena não conseguir maximizar minha conexão com a Internet com essa VPN.

Por favor ajude. Qualquer sugestão será apreciada . Eu estive pesquisando isso desde algumas semanas.

    
por leto 08.02.2011 / 21:04

3 respostas

1

Eu não estou familiarizado com o VIA Padlock, mas ...

  1. A CPU do OpenVPN chega a ~ 100% no topo?
  2. Qual é o tamanho médio de pacote que está sendo encapsulado (a aceleração de criptografia não deve ajudar muito em pacotes pequenos)?
  3. Você poderia compartilhar os resultados do "a velocidade do openssl aes" conosco?

Para referência, posso fornecer meus números de desempenho OpenVPN e OpenSSL para a cifra aes128-cbc e sha1 HMAC no Xeon E5530 2.40GHz quando a criptografia acontece na CPU e no tamanho médio do pacote ~ 1400 bytes: openssl = 1360 Mbit / s openvpn = 320Mbit / s (com a mesma cifra)

Com o motor Intel AES-NI consegui apenas 30% de melhorias para o OpenVPN, enquanto o teste de velocidade OpenSSL melhorou ~ 4 vezes.

Editar:

Você também pode testar o desempenho do OpenVPN com "cipher none" para descartar / comprovar gargalos no código não relacionado à criptografia. A largura de banda que você obterá será o limite superior e o OpenVPN nunca funcionará mais rápido do que isso com qualquer mecanismo de criptografia.

Se o gargalo estiver em código não criptografado, sugiro que você use o IPSec - que ele tenha menos sobrecarga (sem TUNs, sem processos de espaço do usuário, comutadores de contexto, sem pilha TCP / UDP envolvida). Se você ainda quiser manter o OpenVPN, execute vários processos do OpenVPN e tente balancear a carga do tráfego (ajuda somente se você tiver vários núcleos de CPU no roteador).

    
por 09.02.2011 / 02:37
0

O Google nem sempre é seu amigo :-)

Pesquise no arquivo misc @ openbsd mailing list aqui: link

Por último, lembro que a implementação de hardware da VIA deixa muito a desejar.

Além disso, por que usar o pacote OpenVPN? O OpenBSD possui o ipsec vpn e o openSSH integrados e integrados com a pilha de rede e o firewall pf. Tudo isso é suportado por clientes de plataforma cruzada e, sim, até mesmo pelos mais ineficientes de todos: -)

    
por 09.02.2011 / 01:59
0

Ao ver um alto uso da CPU com o OpenVPN, lembre-se de que é um aplicativo userland e, além da criptografia, há muita alternância de contexto necessária para embaralhar os pacotes encapsulados e não encapsulados de e para o kernel, bem como CPU interrompe para a comunicação de rede real. Assumindo um único pacote ping ICMP do final remoto para a rede disponibilizada pelo servidor OpenVPN:

  1. Kernel recebe pacote encapsulado do cliente remoto
  2. As mãos do kernel encapsulam o pacote para o OpenVPN
  3. O OpenVPN descriptografa o pacote e copia a carga na memória
  4. O OpenVPN cria um novo pacote contendo a carga útil e o entrega ao kernel
  5. O kernel envia o pacote para fora da rede local
  6. Kernel recebe pacote de resposta da rede local
  7. Pacote de resposta de mãos do kernel para o OpenVPN
  8. O OpenVPN cria um pacote encapsulado e o entrega ao kernel
  9. O kernel envia um pacote encapsulado ao cliente remoto

Mudanças de contexto acontecem sempre que a execução muda do contexto do kernel para o userland, então 2-3, 4-5, 7-8, 8-9. Compare isso com o IPSec, que é in-kernel, então todo esse encapsulamento / de-encapsulamento acontece no contexto do kernel.

É por isso que, como afirma Ansis, aumentar o throughput de criptografia não se traduz diretamente em uma melhor taxa de transferência do OpenVPN. À medida que a taxa de pacotes aumenta, a mudança de contexto supera os ganhos da aceleração de criptografia de hardware.

    
por 28.05.2011 / 15:59