No passado eu tive o mesmo efeito com o meu ISP (em uma área rural também, embora isso seja apenas uma coincidência).
A raiz da questão é que ele implementou uma limitação de largura de banda apenas na porta 80. Isso era especialmente óbvio com speedtest.net , em que a velocidade inicial atingia o pico, depois diminuía para menos da metade do seu valor máximo.
Descobri por puro acaso que isso não ocorreu no OpenVPN, onde consegui obter o valor da velocidade de pico durante todo o teste speedtest.net . Isso foi possível graças ao fato de que o site com o qual eu me conectei (meu site de trabalho) tem uma conexão muito boa, muito rápida e de grande largura de banda.
Alertado por isso, eu tentei uma grande transferência de arquivos via scp , e eis que eu consegui as mesmas velocidades grandes que com o OpenVPN, ao invés das velocidades mais baixas de http.
Você pode tentar o mesmo e ver se um limite de largura de banda é aplicado nas portas 22 (scp) e 21 (ftp). É mais esclarecedor usar arquivos já comprimidos significativamente como pdf , já que isso excluirá a incidência de compressão per se .
Embora reconhecidamente desleixado, essas limitações de largura de banda ainda são eficazes, já que a maioria das pessoas usa a Internet apenas para baixar páginas da Web.
EDITAR:
Estritamente falando, há uma maneira de testar isso: se você controlar o servidor VPN, poderá interromper qualquer outra atividade no servidor na porta 80 e começar a escutar conexões VPN na porta 80; você também terá que modificar a porta à qual você se conecta no programa do cliente. Agora, se o seu ISP estiver limitando o uso da largura de banda na porta 80, a VPN deverá ter o clock exatamente na mesma velocidade da conexão não-VPN.