pfSense em hardware x64 aumentou o desempenho da rede?

2

O servidor principal tem um ISP de fibra dedicado de 50x50 mbps. Atualmente, temos um roteador com fio Netgear FVS336Gv3 com taxa de transferência WAN para LAN de 300 mbps. Este dispositivo realiza todo o roteamento de / para a internet para o servidor openVPN. O servidor openVPN está sendo executado em um servidor dell x64 semi-dedicado que executa o Ubuntu Server 14.04. Temos uma caixa dell Ubuntu Server 14.04 x64 dedicada que é nosso servidor de arquivos principal, compartilhamentos são hospedados via Samba.

Quando clientes openVPN remotos transferem arquivos de / para o servidor de arquivos principal através do túnel VPN, eles nunca se aproximam para saturar a largura de banda no lado do cliente ou do servidor.

Por exemplo, uma velocidade de download de 20 mbps em um cliente nunca puxa um arquivo pelo túnel VPN a 20 mbps, o que teoricamente poderia acontecer porque a velocidade de upload no servidor de arquivos é de 50 mbps.

A minha pergunta é: se o roteador Netgear FVS336Gv3 fosse descartado para uma caixa dedicada x64 executando pfSense, aumentaria a taxa de transferência através do túnel VPN?

ou

A falta de taxa de transferência no túnel VPN é o resultado da hospedagem de compartilhamentos de arquivos usando o Samba?

Editar:

Estou pensando no último, mas gostaria de ouvir os outros. Nós transferimos arquivos para um servidor Ubuntu remoto via cert. túnel SSH seguro e eu vejo (gráficos de largura de banda Cacti) que estamos saturando a conexão de download remoto em cerca de 20 mbps, o que é muito perto da largura de banda provisionada ISP no site remoto.

Gráfico de largura de banda do roteador Netgear, você pode ver o pico na largura de banda de saída na noite de 08 de julho; este é o nosso backup para o servidor remoto. Durante a semana de trabalho anterior, nunca atingimos a largura de banda de saída de 2 mbps e sei que vários arquivos foram transferidos via Samba e openVPN.

obrigado.

    
por dan 11.07.2016 / 19:21

2 respostas

3

Noções básicas de TCP / IP:

throughput <= TCP buffer size / RTT

Myquestionis:wouldscrappingtheNetgearFVS336Gv3routerforadedicatedx64boxrunningpfSenseincreasethroughputovertheVPNtunnel?

Euduvido,porque...

IsthelackofthroughputovertheVPNtunneltheresultofhostingfilesharesusingSamba?

Definitivamentenão,seuproblemaélatênciaentreoclienteeoservidorOpenVPN(pfsense),eutenhoamesmaconfiguraçãocomovocê:

SMBClient->OpenVPN->WAN<-pfSense<-OpenVPNServer<-LAN->Sambaserver.

Nãoconseguisaturar50mpbs(minhasestaçõesdetrabalhodoWindows7comSMB2.x,taxadetransferênciamáximade10-12mbps,enquantooWindows8e10atualizaramcomSMB3.xdobraramesseresultado)atéqueeuadicionei(confservidor):

sndbuf393216rcvbuf393216push"sndbuf 393216"
push "rcvbuf 393216"

Em links com latência ainda maior, você pode usar buffers maiores, tente testá-los usando passos de 128 KiB.

Reconfigurando o samba para usar;

socket options = TCP_NODELAY IPTOS_THROUGHPUT SO_RCVBUF=65536 SO_SNDBUF=65536

... também é uma boa ideia.

Eu uso: UDP, lzo e toque em dispositivo. Certifique-se de testar (configurando buffers de soquete) usando pelo menos verb 4 no arquivo de configuração do OpenVPN. Procure:

Thu Jun 30 11:39:08 2016 us=90400 nsa310-tryskacze/88.199.144.161:60218 SENT CONTROL [nsa310-tryskacze]: 'PUSH_REPLY,sndbuf 524288,rcvbuf 524288,route-gateway 10.1.2.0,ping 10,ping-restart 30,ifconfig 10.1.2.19 255.255.255.0' (status=1)

Se você quiser entender o problema:

link

link

    
por 12.07.2016 / 05:56
0

A maior parte do trabalho pesado nessa circunstância é feita pelo sistema de servidor OpenVPN, que parece residir em um sistema separado do Netgear. Pela sua descrição, é improvável que a Netgear seja a causa da lentidão, pelo menos não porque você esteja excedendo sua capacidade. Verifique se você não tem nenhuma configuração de tráfego ou configuração de QoS que limita a taxa de transferência da parte externa da VPN.

O

pfSense certamente aumentaria sua taxa de transferência máxima alcançável, mas essa não parece ser a razão do seu desempenho de VPN.

    
por 12.07.2016 / 00:39