Se você não ajustou o MTU, você pode ter problemas de pós-fragmentação (fragmentação ocorrendo após a criptografia) que são bem explicados nesta documentação: link
Você deve tentar reduzir o MTU dentro do túnel em 82 bytes (cabeçalhos GRE + IPSec).
Configurei uma conexão IPsec sobre GRE com um host remoto, ambos são baseados no NetBSD 6.1. O "cliente" está conectado à Internet através de uma fibra de 400Mbps conexão. O "servidor" está localizado em uma rede de 10 Gbps. Ambas as máquinas Placas de rede de 1 Gbps que se comportam perfeitamente, o que significa que ambas alcançam o limite de velocidade do link ao transferir dados fora do túnel IPsec. Ao fazer uma transferência através do túnel, a velocidade cai em um fator de 5 a 10:
conexão direta:
%código%
Conexão IPsec:
/dev/null 27%[====> ] 503.19M 45.3MB/s eta 83s
O túnel é configurado desta forma:
No servidor, que é um NetBSD domU rodando em um debian / amd64 dom0 :
$ cat /etc/ifconfig.xennet0 # server interface up inet 192.168.1.2 netmask 255.255.255.0 inet 172.16.1.1 netmask 0xfffffffc alias $ cat /etc/ifconfig.gre0 create tunnel 172.16.1.1 172.16.1.2 up inet 172.16.1.5 172.16.1.6 netmask 255.255.255.252
O tráfego IPsec é encaminhado do IP público do dom0 para as regras de
/dev/null 2%[ ] 47.76M 6.05MB/s eta 5m 3s
NAT da interface do xennet0 do domU:
-A PREROUTING -i eth0 -p udp -m udp --dport 500 -j DNAT --to-destination 192.168.1.2:500 -A PREROUTING -i eth0 -p esp -j DNAT --to-destination 192.168.1.2 -A PREROUTING -i eth0 -p ah -j DNAT --to-destination 192.168.1.2
No cliente:
$ cat /etc/ifconfig.vlan8 # client public interface create vlan 8 vlanif re0 !dhcpcd -i $int inet 172.16.1.2 netmask 0xfffffffc alias $ cat /etc/ifconfig.gre1 create tunnel 172.16.1.2 172.16.1.1 up inet 172.16.1.6 172.16.1.5 netmask 255.255.255.252
No lado do iptables , eu tentei várias combinações de algoritmos de hash / criptografia, até racoon , mas nada muda realmente, a transferência ainda está presa em um máximo de 6MB / s.
remote node.public.ip {
exchange_mode main;
lifetime time 28800 seconds;
proposal {
encryption_algorithm blowfish;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2;
}
generate_policy off;
}
sainfo address 172.16.1.1/30 any address 172.16.1.2/30 any {
pfs_group 2;
encryption_algorithm blowfish;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
lifetime time 3600 seconds;
}
No cliente:
remote office.public.ip {
exchange_mode main;
lifetime time 28800 seconds;
proposal {
encryption_algorithm blowfish;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2;
}
generate_policy off;
}
sainfo address 172.16.1.2/30 any address 172.16.1.1/30 any {
pfs_group 2;
encryption_algorithm blowfish;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
lifetime time 3600 seconds;
}
O túnel estabelece sem nenhum problema, o único problema aqui é a queda de transferência. Mais uma vez, ao transferir de / para o servidor de / para o cliente sem túnel, a velocidade é ótima, a queda ocorre somente através do IPsec.
Ambas as máquinas são CPUs baseadas em Intel rodando a 2 + GHz, muita memória e muito pouco tempo de CPU consumido por qualquer outra coisa além do encaminhamento / NAT.
Alguém já presenciou tal comportamento? Alguma ideia de onde procurar mais?
Obrigado,
Se você não ajustou o MTU, você pode ter problemas de pós-fragmentação (fragmentação ocorrendo após a criptografia) que são bem explicados nesta documentação: link
Você deve tentar reduzir o MTU dentro do túnel em 82 bytes (cabeçalhos GRE + IPSec).