Ao transferir grandes quantidades de dados usando um cliente OpenVPN a partir de uma conexão de internet específica, a conexão à Internet da rede de servidores OpenVPN é completamente interrompida. Outros clientes do OpenVPN não resultam no impacto do desempenho na transferência dos mesmos dados.
A rede de servidores tem uma conexão de internet assíncrona com upstream de 9600kbit / s (medido com iperf ) e cerca de 50MBit / s a jusante.
A transferência do servidor OpenVPN para o cliente específico usa apenas cerca de 2-3MBit / s do upstream disponível de ~ 10MBit / s. O cliente tem um downstream muito maior, então isso não pode ser o problema.
Primeiro, descobri que os pacotes OpenVPN que vão para esse cliente específico ficam fragmentados, então ajustei manualmente a configuração tun-mtu no OpenVPN usando a seguinte configuração do lado do servidor:
tun-mtu 1492
push "tun-mtu 1492"
Este não era o problema raiz, então tentei configurar o traffic shaping usando tc no roteador linux entre o modem e a rede do lado do servidor.
Este é o script que eu uso para configurar o traffic shaping ( eth2 é a interface conectada à internet):
tc qdisc add dev eth2 root handle 1: htb default 12
tc class add dev eth2 parent 1: classid 1:1 htb rate 9500kbit
tc class add dev eth2 parent 1:1 classid 1:10 htb rate 2Mbit ceil 9500kbit prio 0
tc class add dev eth2 parent 1:1 classid 1:11 htb rate 2Mbit ceil 9500kbit prio 1
tc class add dev eth2 parent 1:1 classid 1:12 htb rate 2Mbit ceil 9500kbit prio 2
tc class add dev eth2 parent 1:1 classid 1:13 htb rate 1Mbit ceil 9500kbit prio 3
tc class add dev eth2 parent 1:1 classid 1:14 htb rate 1Mbit ceil 3Mbit prio 4
# match tcp ack packets
tc filter add dev eth2 parent 1:0 protocol ip prio 0 u32 \
match ip protocol 6 0xff \
match u8 0x05 0x0f at 0 \
match u16 0x0000 0xffc0 at 2 \
match u8 0x10 0xff at 33 \
flowid 1:10
# match OpenVPN traffic in both directions
tc filter add dev eth2 parent 1:0 prio 1 u32 match ip sport 1194 0xffff match ip protocol 0x11 0xff flowid 1:14
tc filter add dev eth2 parent 1:0 prio 2 u32 match ip dport 1194 0xffff match ip protocol 0x11 0xff flowid 1:14
# match traffic using TOS flags to three bands mainly according to man 8 tc-prio
tc filter add dev eth2 parent 1:0 prio 3 u32 match ip tos 0x10 0x18 flowid 1:11
tc filter add dev eth2 parent 1:0 prio 4 u32 match ip tos 0x02 0x1E flowid 1:13
tc filter add dev eth2 parent 1:0 prio 5 u32 match ip tos 0x08 0x18 flowid 1:13
O objetivo era priorizar todo o tráfego maior que o tráfego OpenVPN, além de fornecer apenas uma pequena quantidade da largura de banda disponível.
Isso ainda não ajudou. Não consegui descobrir nenhuma retransmissão ao analisar o tráfego usando tcpdump .
Ao dizer "a conexão de rede é completamente quebrada", quero dizer que as outras conexões de Internet quase sempre atingem o tempo limite e as velocidades de transferência são muito lentas (mais lentas que 1kbit / s). Tentar usar a internet de outras maneiras que a conexão OpenVPN não afeta a transferência de dados do OpenVPN que atrasa tudo.
A velocidade de transferência 'lenta' do OpenVPN não é um problema real, em contraste com a conexão de internet 'quebrada' da rede de servidores.
Quais causas podem ser responsáveis pela falha na rede?
Onde eu poderia investigar mais?