Nota: Esta é a revisitação de um post do ano passado onde abordei o tema de nos mantermos seguros enquanto usamos free wifi de férias e como bónus uma forma de poupar tráfego enquanto se usa redes 3G/4G do operador.
Estou a acabar um post idêntico, utilizando IPSEC ao invés de OpenVPN, para quem tem mais que um ip publico, ou consiga ter acesso diretamente a porta de ESP.
Espero que gostem!

Olá a todos,

Com agosto a chegar, a quantidade de tráfego 3G que temos nos nossos telemóveis estando fora de casa irá certamente escassear.

Com a proliferação dos acessos Fonera e Meo Wifi, o wifi gratuito é uma solução, mas que coloca alguns problemas sérios de segurança – a Gartner a cerca de 2 anos publicou que 70% dos hotspots públicos estavam sobre algum tipo de sniffing ou auditoria.

Como resolver a questão da segurança e evitar que voltemos ao estonteante mundo da internet RDIS em 1999 (128K/s para os leitores mais novos) quando batemos na política de utilização responsável (?!) imposta pelos operadores?

Nada mais fácil. Usar um cliente openvpn com compressão de tráfego ativa.

Os componentes nesta receita são: um servidor openvpn e um cliente  (seja em IOS seja em Android)

Provavelmente já devem ter um servidor openvpn em qualquer sitio. No meu caso está na pfsense de perímetro do meu homelab.

O resto é simples, sendo o truque instalarem um agente de openVPN no vosso telemóvel, ou tablet.

No vosso servidor de openvpn não se esqueçam de configurar três opções:

Adaptive Compression: ON
Server Mode: Remote Access – User auth
Redirect Gateway:  Enabled

O primeiro garante um acesso por user/password. É menos seguro que por chaves, mas mais simples quando se tem que carregar uma chave no telemóvel.
A segunda em si, é o que faz o truque em si para a poupança de tráfego através da compressão e descompressão de tráfego via openvpn.
Finalmente a terceira opção garante que todo o tráfego desde o vosso telemóvel/tablet é forçado a entrar via o túnel criado pela openvpn.

Nota: com a terceira opção ativada, não podem usar aplicativos meo go, meo music ou outros semelhantes que não contem para tráfego internet utilizado. Ao ativarem esta opção todo o tráfego vai via a vossa gateway openvpn, e assim passa a contar para tráfego – por exemplo a PT separa o tráfego pelo IP destino. Como vai via outro IP destino já conta para tráfego.
A solução nestes casos, é quando quiserem usar estas aplicações, desativem a vossa openvpn.

Em termos de configuração dos serviços numa forma mais genérica temos no servidor:

dev ovpns3
verb 3
dev-type tun
tun-ipv6
dev-node /dev/tun3
writepid /var/run/openvpn_server3.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto tcp-server
cipher CAMELLIA-256-OFB
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local XXX.XXX.XXX
tls-server
server XXX.XXX.XXX.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc
client-cert-not-required
username-as-common-name
auth-user-pass-verify “/usr/local/sbin/ovpn_auth_verify user ‘Local Database’ false server3” via-env
tls-verify “/usr/local/sbin/ovpn_auth_verify tls ‘nuneshiggs.com’ 1 “
lport 61112
management /var/etc/openvpn/server3.sock unix
push “route XXX.XXX.0.0 255.255.0.0”
push “dhcp-option DNS XXX.XXX.XXX”
push “dhcp-option DNS XXX.XXX.XXX”
push “register-dns”
push “redirect-gateway def1”
client-to-client
ca /var/etc/openvpn/server3.ca
cert /var/etc/openvpn/server3.cert
key /var/etc/openvpn/server3.key
dh /etc/dh-parameters.4096
tls-auth /var/etc/openvpn/server3.tls-auth 0
comp-lzo adaptive
log         /tmp/home_server_log_openvpn.log
log-append  /tmp/home_server_log_openvpn.log

Nota: não se esqueçam de configurar as vossas regras IP para permitir os acessos desde a vossa rede openvpn, e garantam a existência dos vossos certificados de CA e keys respetivas.

Do lado do cliente temos:

dev tun
persist-tun
persist-key
cipher CAMELLIA-256-OFB
auth SHA1
tls-client
client
resolv-retry infinite
remote XXXX.XXXXX.com 1493 tcp-client
lport 0
auth-user-pass
ca xxxxxxx-ca.crt
tls-auth xxxxx-TCP-xxxxx-tls.key 1
ns-cert-type server
comp-lzo

A configuração dos remote’s é igualmente muito simples, existindo vários clientes openvpn tanto para IOS como para Android:

Android: https://play.google.com/store/apps/details?id=net.openvpn.openvpn&hl=en
IOS: https://itunes.apple.com/us/app/openvpn-connect/id590379981?mt=8

Ambos estão disponíveis e instaláveis sem root/jailbreak através das respetivas app stores, com documentação extensiva de como os configurarem.
É ainda mais simples utilizando appliances openvpn, pois tem export utilities que vos gera pacotes .ovpn com toda a configuração necessária.

Pensamentos finais,

O procedimento em si tem tradeoff’s em termos de velocidade e consumo extra de bateria nos telemóveis (devido a compressão e descompressão dos dados).
No entanto, ganha-se bastante em segurança – caso usem o procedimento para aceder via public wifi’s ou para poupar em tráfego utilizado – notar o a diferença no tamanho de dados descomprimidos vs o tamanho com a compressão no gráfico abaixo. A mesma escala pode ser utilizada para a quantidade de dados transmitidos comprimidos ou descomprimidos.

Infelizmente não irá eliminar a PUR, ou evitar totalmente o downgrade da velocidade pelo operador, mas irá fazer que isto só aconteça lá mais para a frente no mês 😉

Existem no entanto, dados que não podem ser comprimidos, ou tem baixa taxa de compressão pela sua natureza, por exemplo ficheiros jpg ou mp4, mas para todo o texto (por exemplo texto da stream de um jornal ou de um social media site), a compressão efetiva faz muita diferença no resultado final.

Nota: gráfico tirado da compressão de ficheiros e dados obtido via google – tamanho menor é melhor.

Caso tenham duvidas ou sugestões, estou sempre contactável através de nuno at nuneshiggs dot com.

Abr,
Nuno