IPSec com ou sem L2TP?

Question

Estou me referindo a essa pergunta . E para ser claro: Isto não é realmente sobre o antigo debate PPTP vs L2TP. ; -)

Eu configurei o racoon com sucesso como um servidor IKE sem qualquer implementação de L2TP em execução e funciona muito bem. Eu posso estabelecer um túnel do meu laptop para o servidor VPN e usá-lo como um gateway de internet. Tanto quanto eu posso ver todos os pacotes IP são encapsulados de forma segura. Voilà, isso é tudo que eu queria. Mas, oops, é apenas o OS X / iOS que suporta esse tipo de VPN "simples IPSec", mas também preciso dar suporte a outras plataformas. Todos os outros sistemas operacionais, incluindo o Windows e o Android, parecem precisar da conexão PPP adicional estabelecida usando o L2TP usando software como o xl2tpd. Eu estava curioso, então eu configurei novamente com o racoon + xl2tpd e criei um túnel L2TP / IPSec. E funciona exatamente como aconteceu sem o L2TP.

Então, qual é o benefício de usar o L2TP? Sim, eu posso tunelar outros protocolos como o X.25, mas qualquer coisa diferente de IP raramente é necessária pela grande maioria dos usuários. Eu posso assumir as razões pelas quais o MS está fazendo isso mais complexo do que o material da VPN tem que ser. Mas pelo menos não consigo entender por que o Android ainda precisa dessa camada L2TP, o que, na minha opinião, apenas adiciona complexidade e sobrecarga. E sim, eu sei que há um software cliente extra para superar os limites do sistema operacional.

Mesmo com a autenticação, não há diferença: a autenticação remota é normalmente feita usando chaves pré-compartilhadas ou certificados e a autenticação do usuário é feita via XAuth ou CHAP / PAP. - Estou simplificando aqui, mas você sabe o que quero dizer.

Alguém sabe por que o L2TP ainda é o padrão com o IPSec? Estou faltando alguma coisa?

    

Answer 1

O Android desde o 4.0 oferece suporte a IPsec simples fora da caixa. E há vários aplicativos para 4.x que fornecem outros protocolos VPN em dispositivos não-raiz (por exemplo, IKEv2 / IPsec com o strongSwan VPN Client ).

Desde o Windows 7, você pode usar o cliente IKEv2 / IPsec integrado. O racoon concedido não suporta o IKEv2, mas existem outras implementações de código aberto que fazem (por exemplo, strongSwan ou Libreswan ).

Does anyone know why L2TP is still the standard way with IPSec?

Eu não diria que é o caminho padrão, como por exemplo O Windows 7 e o mais recente tentam primeiro o IKEv2, mas concordo que os clientes ainda o oferecem com bastante destaque.

Uma das razões para seu sucesso inicial foi provavelmente a possibilidade de reutilizar a infraestrutura PPP existente para conexões dial-up (além de ser mais segura e padronizada que o PPTP). E como as instalações L2TP existem há muito tempo e foram implantadas de forma bastante difundida, qualquer cliente tinha (e ainda tem) suporte para isso. Isso facilita, é claro, para provedores de VPN, pois eles podem reduzir o número de tecnologias VPN oferecidas. Isso, no entanto, reduz o incentivo para implementar outros protocolos nos clientes.

Também poderia haver problemas de licenciamento impedindo o uso de outros protocolos, por exemplo, as implementações IKEv2 mencionadas acima são licenciadas sob GPL, que a Apple no iOS e o Google no Android tendem a evitar em favor de softwares licenciados mais permissivamente como o racoon ( que ambos usam em seus produtos).

    

Answer 2

No início (há muito tempo, antes que a implementação do BSD IPsec fosse integrada ao kernel do Linux), não era possível usar uma VPN IPsec em um gateway NAT, porque não era possível o IPsec do NAT. O IPsec foi desenvolvido para o IPv6, que não conhece mais a NAT, e usar o IPsec para IPv4 sempre foi uma espécie de invasão. Não ter NAT para os chamados guerreiros da estrada usando o IPv4 foi um não-ir. A única maneira de fazê-lo funcionar no 90 foi usar o L2TP, porque o L2TP funciona em cima do UDP e o NAT é possível. A Cisco pegou essa solução e a implementou em seus VPN-Concentrators. Este é o momento em que se tornou um "padrão". E, para ser compatível com a Cisco, muitos outros fornecedores a implementaram. Essa é a razão pela qual a Apple a implementou e por que o Android também a suporta.

Mas o tunelamento de quadros Ethernet da camada 2 através do túnel IPsec nunca foi uma ótima idéia para uma comunicação somente IP. No 90, havia outros protocolos que precisavam de ponte como o IPX, mas hoje em dia todos falam IP. E, a fim de se livrar da camada 2 sobrecarga quadro RFC 3948 propôs o "encapsulamento UDP de pacotes IPsec ESP". Isso funciona também colocando os protocolos ESP e AH em pacotes UDP e por esse NAT é possível. Mas evita qualquer quadro de camada 2. Esta é a solução moderna que todos devem tentar primeiro. Usar o L2TP é o caminho legado, que existe apenas para compatibilidade com versões anteriores.