Olá a todos,

Desde o post inicial sobre os acessos de férias através de openVPN, tenho andado para fazer uma atualização do mesmo, mas desta vez com IPSEC, que é nativo de 99% dos telemóveis Android e IOS.
Sei que existem bastantes ROM’s que não suportam os módulos de openVPN e chegou então a altura de corrigir esta lacuna.

Com o verão em full swing, o plafond de tráfego 3G que temos nos nossos telemóveis começa a escassear.

Com a proliferação dos acessos NOS/FON e MEO wifi, o WIFI gratuito é certamente 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 não descritiva.

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 IPSEC com compressão de tráfego ativa em modo de road warrior.

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

No meu caso está no cluster pfsense de perímetro do meu homelab que serve igualmente como concentrador de openVPN.

O resto é simples, sendo o truque apenas configurarem o agente de ipsec no vosso telemóvel, ou tablet.

No lado da firewall, deverão ir a VPN, IPSEC, Mobile Client:

Deveremos ativar as IKE extensions, o local onde queremos autenticar o nosso utilizador (se local ou num IPA/LDAP), a rede de túnel que iremos utilizar (nota que não pode ser nenhuma rede que exista localmente na nossa rede/laboratório), definir os DNS que os clientes IPSEC irão utilizar e um banner a ser mostrado aos clientes quando completem a ligação.

Em seguida criar uma pre-shared key para a nossa ligação:

Nos advanced settings ativar a IP compression:

Finalmente faremos a configuração do túnel em si:

Em primeiro lugar, configurar a key exchange para auto, e a interface de rede onde o processo do servidor de IPSEC irá estar a escuta.

Na phase 1, colocar as configurações como apresentadas, garantido que o peer identifier está idêntico ao peer identifier configurado no passo anterior de pre-shared keys e a pre-shared key configurada anteriormente.

Nota: Os algoritmos e cifras apresentadas são o denominador comum mais baixo que são suportados nos telemóveis e tablets android que tive acesso.
Não são portanto as mais seguras mas as mais compatíveis. Será questão de testarem com os vossos equipamentos e encontrarem o equilíbrio entre funcionalidade e segurança.

Finalmente ativem o NAT Transversal e o Responder only, se estiverem como eu através de um router que só suporte TCP/IP e não ESP.

Em seguida, será altura de configurar as permissões de tráfego na firewall em si (terá aparecido entretanto uma tab de IPSEC) e os clientes IPSEC que se irão ligar.

Um excelente howto para configuração dos clientes pode ser encontrado aqui.

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, encriptação, desencriptaçã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.

Fica ainda o ultimo alerta que caso usem serviços de tráfego sem contabilização – por exemplo meogo ou substitutos do meo music que não contam para tráfego em telemóveis MEO – tem de ter a VPN desativada sob pena de ter o tráfego gratuito contabilizado (está a acontecer um redirect de tráfego que por não ir diretamente para os servidores da PT é contabilizado).

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

Abraço!
Nuno