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 4G que temos nos nossos telemóveis começa a escassear.
Com a proliferação dos acessos NOS/FON, MEO wifi e cafés com internet WIFI gratuita estes acessos são certamente uma solução, mas que coloca alguns problemas sérios de segurança – a Gartner a cerca de 2 anos publicou que 80% 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 opnSense de perímetro do meu homelab que serve igualmente como concentrador de openVPN e ipsec.
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, Tunnel Settings:
No meu caso tenho já dois endpoints de vpn criados, um para o meu acesso a internet e ao homelab, e o outro para salvaguardar a privacidade dos meus filhos quando andam na internet fora de casa.
Em seguida e após clicarem no + no fundo do menu, ser-vos-a apresentado um menu como o seguinte onde deverão escolher os seguintes pontos a semelhança dos meus.
Nota que no caso da interface, devem escolher a interface que está virada para a internet – no meu caso especifico a interface tem o ip 192.168.1.1 -, ou se tiverem o router do operador a frente, deverão nele efetuar o NAT/PAT para os portos de IPSEC c/Nat:
Deveremos escolher um My Identifier especifico a nossa escolha – Em alguns casos chamado de Group Name – e uma chave pre-shared, tambem chamado de pre-shared secret.
Seguidamente será altura de configurar o túnel ESP que na pratica é o que transporta o nosso tráfego.
Nesta secção devem ter atenção aos seguintes itens: address – 0.0.0.0/0 – é para terem acesso a tudo via a VPN e não apenas a um endereçamento especifico.
Algoritmos de encriptação, escolhendo o mais alto e complexo possível, tendo em conta sempre da existência de suporte por parte do equipamento cliente – telemóvel, tablet, etc.
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 e são utilizados no meu ambiente.
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.
Em seguida iremos configurar a parte de suporte ao cliente móvel, o chamado de road warrior.
Nesta secção devem indicar uma rede de endereços que irá ser dada a todos os clientes ipsec que se liguem neste endpoint, um backend de autenticação caso tenham como eu IPA ou em alternativa possuam um LDAP ou AD e os vossos servidores internos de DNS, ou em alternativa os do vosso operador ou outros DNS providers que sejam free.
Finalmente coloquem o NAT Transversal em Force 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, sabem onde me podem encontrar.
Abraço!
Nuno