Openvpn, encaminhar pacotes muito lentamente

10

Reiniciei meu servidor e surgiu um problema estranho. Estou executando no ArchLinux, os clientes são Ubuntu, Android e Mac.

O problema é que o acesso à Internet pelos clientes é lento, cerca de 2ko / se pára lentamente.

Mas o download de algo do servidor para o cliente diretamente é feito a toda velocidade. E, obviamente, a internet do servidor está em sua velocidade máxima (40mo / s).

Não sei o que aconteceu com a reinicialização, mas esse problema está presente em todos os clientes e está relacionado apenas ao tráfego que o openvpn encaminha para a internet.

EDIT: Tentei com tcp, não resolveu. EDIT: testado várias configurações de fragmento / mtu, sem alterações.

Aqui estão todos os meus confs:

╭─<root@Alduin>-</etc/openvpn>-<1:45:07>-◇
╰─➤ cat Alduin.conf ccd/Thunderaan
local 212.83.129.104
port 1194
proto udp
dev tun
ca keys/ca.crt
cert keys/Alduin.crt
key keys/Alduin.key
dh keys/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 10.8.0.1"
client-to-client
keepalive 5 60
ping-timer-rem
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
client-config-dir ccd
topology subnet

ccd from here +++++++++++++++


ifconfig-push 10.8.0.2 255.255.255.0
push "redirect-gateway def1"

Conf do cliente:

client
dev tun
proto udp
remote 212.83.129.104 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert name.crt
key name.key
ns-cert-type server
comp-lzo
verb 3

e alguma saída que pode ajudá-lo: 

╭─<cubox@Alduin>-<~>-<1:49:43>-◇
╰─➤ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether b8:ac:6f:94:e2:4e brd ff:ff:ff:ff:ff:ff
    inet 88.190.15.135/24 scope global eno1
       valid_lft forever preferred_lft forever
    inet 212.83.129.104/32 scope global eno1
       valid_lft forever preferred_lft forever
    inet6 2001:bc8:300a:dead::b12d/64 scope global
       valid_lft forever preferred_lft forever
    inet6 2a01:e0b:1000:15:baac:6fff:fe94:e24e/64 scope global dynamic
       valid_lft 2592000sec preferred_lft 604800sec
    inet6 fe80::baac:6fff:fe94:e24e/64 scope link
       valid_lft forever preferred_lft forever
3: eno2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether b8:ac:6f:94:e2:4f brd ff:ff:ff:ff:ff:ff
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tun0
       valid_lft forever preferred_lft forever
╭─<cubox@Alduin>-<~>-<1:49:47>-◇
╰─➤ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         88-190-15-1.rev 0.0.0.0         UG    0      0        0 eno1
10.8.0.0        *               255.255.255.0   U     0      0        0 tun0
88.190.15.0     *               255.255.255.0   U     0      0        0 eno1
╭─<cubox@Alduin>-<~>-<1:49:51>-◇
╰─➤ route -6
Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
::1/128                        ::                         U    256 0     0 lo
2001:bc8:300a:dead::/64        ::                         U    256 0     0 eno1
2a01:e0b:1000:15::/64          ::                         UAe  256 0     0 eno1
fe80::/64                      ::                         U    256 0     0 eno1
::/0                           fe80::225:45ff:fef6:947f   UGDAe 1024 2     0 eno1
::/0                           ::                         !n   -1  1  1891 lo
::1/128                        ::                         Un   0   2  5227 lo
2001:bc8:300a:dead::/128       ::                         Un   0   1     0 lo
2001:bc8:300a:dead::b12d/128   ::                         Un   0   1   131 lo
2a01:e0b:1000:15::/128         ::                         Un   0   1     0 lo
2a01:e0b:1000:15:baac:6fff:fe94:e24e/128 ::                         Un   0   3 29356 lo
fe80::/128                     ::                         Un   0   1     0 lo
fe80::baac:6fff:fe94:e24e/128  ::                         Un   0   1   311 lo
ff00::/8                       ::                         U    256 0     0 eno1
::/0                           ::                         !n   -1  1  1891 lo



-A POSTROUTING -s 10.8.0.0/24 -o eno1 -j MASQUERADE # The iptables rule

A regra iptables aqui é a única que está ativa no servidor.

╰─➤ tc qd
qdisc mq 0: dev eno1 root
qdisc pfifo_fast 0: dev tun0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

EDIT: Aqui está um log da conexão do cliente Archlinux.

Oct  2 16:54:17 Groat ovpn-openvpn[9216]: OpenVPN 2.2.1 x86_64-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Feb 13 2013
Oct  2 16:54:17 Groat ovpn-openvpn[9216]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Oct  2 16:54:17 Groat ovpn-openvpn[9216]: LZO compression initialized
Oct  2 16:54:17 Groat ovpn-openvpn[9216]: Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Oct  2 16:54:17 Groat ovpn-openvpn[9216]: Socket Buffers: R=[212992->131072] S=[212992->131072]
Oct  2 16:54:17 Groat ovpn-openvpn[9216]: Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Oct  2 16:54:17 Groat ovpn-openvpn[9216]: Local Options hash (VER=V4): '41690919'
Oct  2 16:54:17 Groat ovpn-openvpn[9216]: Expected Remote Options hash (VER=V4): '530fdded'
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: UDPv4 link local: [undef]
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: UDPv4 link remote: [AF_INET]212.83.129.104:1194
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: TLS: Initial packet from [AF_INET]212.83.129.104:1194, sid=edfcb034 3452d72c
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: VERIFY OK: depth=1, /C=FR/ST=FR/L=Paris/O=Dragonborn/CN=Dragonborn_CA/[email protected]
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: VERIFY OK: nsCertType=SERVER
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: VERIFY OK: depth=0, /C=FR/ST=FR/L=Paris/O=Dragonborn/CN=Dragonborn/[email protected]
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: [Dragonborn] Peer Connection Initiated with [AF_INET]212.83.129.104:1194
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: SENT CONTROL [Dragonborn]: 'PUSH_REQUEST' (status=1)
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 10.8.0.1,route 212.83.129.0 255.255.255.0,route-gateway 10.8.0.1,topology subnet,ping 5,ping-restart 60,redirect-gateway def1,ifconfig 10.8.0.3 255.255.255.0'
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: OPTIONS IMPORT: timers and/or timeouts modified
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: OPTIONS IMPORT: --ifconfig/up options modified
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: OPTIONS IMPORT: route options modified
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: OPTIONS IMPORT: route-related options modified
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: ROUTE default_gateway=192.168.1.254
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: TUN/TAP device tun0 opened
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: TUN/TAP TX queue length set to 100
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: /sbin/ifconfig tun0 10.8.0.3 netmask 255.255.255.0 mtu 1500 broadcast 10.8.0.255
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: /sbin/route add -net 212.83.129.104 netmask 255.255.255.255 gw 192.168.1.254
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.8.0.1
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.8.0.1
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: /sbin/route add -net 212.83.129.0 netmask 255.255.255.0 gw 10.8.0.1
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: Initialization Sequence Completed

EDIT: Aqui está um tcpdump do servidor baixando diretamente um arquivo: http://sprunge.us/aaJX Aqui está o cliente baixando esse recurso: http://sprunge.us/WUCC e aqui está um cliente normal de outro openvpn ( servidor): http://www4.slashusr.com/57552.tcpdump

EDIT: Conforme solicitado nos comentários, aqui estão as capturas brutas do tcpdump. A captura tun0 do servidor falhou, não sei por quê. Servidor mostrando fora aqui , cliente mostrando tun0 aqui , cliente mostrando fora aqui e servidor baixando diretamente o arquivo aqui .

EDIT: O servidor está executando um i3, que não é usado a qualquer momento (nem mesmo durante o uso do openvpn). O mesmo para o cliente, i7 totalmente ocioso.

EDIT: O problema ainda está aqui. Por favor ajude :(

linux iptables routing ip openvpn Cubox
fonte
Eu suponho que você já viu algumas capturas com wireshark / tcpdump? A resposta quase certamente pode ser encontrada em uma captura, se você capturar no lugar certo.
Zoredache
Eu tenho um tcpdump da interface eno1 em um download do cliente e um do servidor (do mesmo arquivo). E um de um cliente openvpn funcional também. Vou editar a pergunta.
Cubox 30/09
Você pode adicionar informações da CPU do cliente e do servidor enquanto o tráfego está sendo transferido?
precisa saber é o seguinte
No seu tcpdump, não vejo tráfego lento (pode ser muito curto). Todo cliente recebe o mesmo endereço IP 10.8.0.2? Você pode omitir isso e enviar uma rota para sua rede 212.83.129.0?
1--13
Cada cliente tem seu próprio ccd com seu próprio endereço IP. Não entendo o que você quer dizer com rota para a rede.
Cubox

Respostas:

1

Não tenho certeza se é a mesma causa, mas acho que vale a pena ajustar sobre tun-mtu e mssfix, conforme mencionado em openvpn-on-android-tcp-retransmissions-after-openvpn-server-reboot

EDIT: Achei que este também pode ser útil [RESOLVIDO] Desempenho inaceitável do openVPN Alterando um parâmetro do kernel: net.inet.ip.fastforwarding = 1 (adicione /etc/sysctl.conf no servidor linux)

Wutiphong
fonte
Obrigado pela resposta. Alterar as opções tun-mtu e mssfix não ajudou. A configuração fastworwarding não existe no Linux. Somente kernels BSD.
Cubox 21/10
0

O servidor vpn também é o servidor gateway? tente remover o gateway de envio, seus clientes precisam ter apenas uma rota adicional.

Alin Andrei
fonte
Onde você vê uma opção de gateway push?
Cubox
Nas opções do CCD, há um gateway de redirecionamento. Você precisa verificar se há uma rota estática nos clientes para o GW real deles.
MeadstroM
Há sim. Os clientes podem conversar com qualquer coisa na internet, apenas o fazem devagar.
`` Cubox ''
0

Sua regra de iptables pós-rastreamento parece estranha, tente isso

-A POSTROUTING -s 10.8.0.0/24 -o eno1 -j MASQUERADE

em vez do SNAT e exclua um dos IPs no eno1, se você não precisar dos dois. Dois endereços IP públicos no que parece ser uma interface Ethernet parecem estranhos. Por que essa configuração?

Meu palpite é que seu servidor openvpn está repetindo e soltando pacotes, levando a esse problema.

AntonioP
fonte
Eu tenho a regra do disfarce agora, não resolveu o problema. Eu tenho dois está no meu servidor, com um deles sendo o failover e o outro o principal. Para ter um servidor com quatro ips na interface eth0 (em outro servidor Archlinux) por mais de um ano, posso dizer-lhe que múltiplos ips não são o problema aqui ...
Cubox
0

Você executa seu próprio servidor DNS internamente? Eu tive problemas com minha rede quando estava executando uma configuração de powerdns para dns internos, mas não tinha uma zona reversa configurada corretamente. O Wireshark forneceu as respostas nesse caso.

Peter Nunn
fonte