Comparativo de VPN site a site: L2TP, GRE, DSVPN, IPSec e MPLS

Sete formas de conectar uma filial — e por que a escolha importa

Erre nessa decisão e você recabeará a WAN em seis meses.

Cada uma dessas sete tecnologias pode conectar uma filial à matriz por meio de uma WAN. O que elas não têm em comum é a criptografia, a tolerância a IP dinâmico, o suporte a multicast, ou quantas filiais suportam antes que a configuração vire um trabalho em tempo integral. Escolher a errada geralmente não falha de imediato — apenas se torna silenciosamente doloroso na décima segunda filial, ou no dia em que um regulador pergunta por que os dados não estão criptografados.

Esta nota é uma referência de planejamento para a seleção de tecnologia de interconexão de filiais, construída a partir do capítulo de VPN site a site do guia de configuração de roteadores AR da Huawei. Abrange L2TP, GRE, DSVPN, IPSec, BGP/MPLS IP VPN, VLL e PWE3 — uma seção por tecnologia, cada uma com seu cenário de aplicação real, seus prós e contras reais e um esqueleto de configuração básica literal. Se você precisar de detalhes sobre executar IPSec sobre uma dessas, fazer o IPSec atravessar NAT, ou construir um design IPSec de interface de túnel virtual, essas são notas separadas: DSVPN sobre IPSec, Interface de túnel virtual IPSec, e Travessia de NAT IPSec.

Qual você realmente precisa

Comece pelo que o tráfego precisa, não pela tecnologia que você já conhece.

Destaques de configuração, tecnologia por tecnologia

Cenário, trade-offs reais e o esqueleto de CLI básico — para cada uma das sete.

L2TP — VPN de acesso remoto e discagem multiusuário

O habitat natural do L2TP é o acesso remoto e a discagem: um LAC (geralmente o próprio gateway da filial, ou um usuário remoto terminado em PPPoE) tuneliza sessões PPP até um LNS na matriz, que autentica o usuário e atribui um endereço de um pool local. É a escolha certa quando o lado da filial é uma população grande e mutável de usuários individuais de discagem, em vez de um enlace site a site fixo — a autenticação baseada em RADIUS e a atribuição de IP por usuário vêm quase de graça. O que o L2TP não oferece é criptografia: o túnel é um encapsulamento PPP sobre UDP em texto claro, então qualquer coisa sensível precisa de L2TP sobre IPSec por cima. Prós: autenticação em nível de usuário, endereçamento por usuário, funciona sobre qualquer caminho IP, suporte a RADIUS. Contras: sem criptografia nativa, a senha de autenticação do túnel deve corresponder exatamente em ambas as extremidades, não é uma tecnologia de malha completa entre filiais.

-- LAC side --
l2tp enable
#
interface Virtual-Template1
 ppp authentication-mode chap
#
l2tp-group 1
 tunnel password cipher %@%@AbCd1234%@%@
 tunnel name lac1
 start l2tp ip 202.1.1.1 domain aaa.com

-- LNS side --
l2tp enable
#
ip pool 1
 gateway-list 10.1.1.1
 network 10.1.1.0 mask 255.255.255.0
#
interface Virtual-Template1
 ppp authentication-mode chap
 remote address pool 1
 ip address 10.1.1.1 255.255.255.0
#
l2tp-group 1
 allow l2tp virtual-template 1 remote lac1
 tunnel password cipher %@%@AbCd1234%@%@
 tunnel name lns

GRE — o túnel mais simples, com menos garantias

O GRE é o mais simples dos sete: envolve um pacote IP dentro de outro pacote IP entre dois extremos de túnel fixos, e isso é essencialmente todo o seu conjunto de recursos. Seu valor real é transformar duas LANs remotas no que parece um enlace diretamente conectado, o que permite que um protocolo de roteamento dinâmico como OSPF funcione diretamente sobre ele — útil quando as tabelas de roteamento da filial e da matriz precisam permanecer sincronizadas automaticamente em vez de por rotas estáticas. O GRE não carrega criptografia nem autenticação próprias; na internet pública, normalmente é combinado com IPSec (IPSec sobre GRE), e os próprios endereços de origem/destino do GRE precisam ser alcançáveis e, na maioria dos projetos, estáticos. Prós: extremamente simples, suporta multicast e roteamento dinâmico sobre o túnel, funciona em quase qualquer rede IP. Contras: sem criptografia ou autenticação, mais adequado para ponto a ponto, o endereçamento origem/destino precisa ser estável.

interface Tunnel0/0/1
 ip address 10.3.1.1 255.255.255.0
 tunnel-protocol gre
 source 20.1.1.1
 destination 30.1.1.2
#
ip route-static 10.2.1.0 255.255.255.0 Tunnel0/0/1

DSVPN — hub-and-spoke que evolui para spoke-to-spoke

O DSVPN (Dynamic Smart VPN) é no que o GRE se transforma quando um hub precisa falar com dezenas de spokes cujos endereços IP públicos mudam: uma interface de túnel mGRE no hub aceita registros dos spokes via NHRP, de modo que cada spoke pode aparecer e reaparecer em um novo endereço IP sem que ninguém mexa na configuração do hub. Com nhrp shortcut e nhrp redirect, o tráfego spoke a spoke pode até construir um túnel direto entre duas filiais em vez de sempre passar pelo hub. Um segundo hub pode ser adicionado puramente para resiliência, diferenciado pelo custo OSPF para que os spokes prefiram o hub primário e façam failover automaticamente. Assim como o GRE simples, o DSVPN não carrega criptografia por si só; projetos em produção quase sempre executam IPSec sobre DSVPN — veja a nota dedicada DSVPN sobre IPSec para essa ligação. Prós: escala para grandes quantidades de filiais com uma única configuração de hub, tolera endereçamento dinâmico de spokes, resiliência com hub duplo, o atalho spoke a spoke evita o gargalo do hub. Contras: ainda sem criptografia nativa, requer que todo dispositivo tenha alcançabilidade na rede pública, projetos com hub duplo não podem compartilhar uma sub-rede.

-- Hub --
interface Tunnel0/0/0
 ip address 172.16.1.1 255.255.255.0
 tunnel-protocol gre p2mp
 source Ethernet1/0/0
 nhrp entry multicast dynamic
 ospf network-type broadcast

-- Spoke --
interface Tunnel0/0/0
 ip address 172.16.1.101 255.255.255.0
 tunnel-protocol gre p2mp
 source Ethernet1/0/0
 nhrp entry 172.16.1.1 1.1.1.1 register
 ospf network-type broadcast

IPSec — o que oferece criptografia de verdade

O IPSec é a tecnologia desta lista realmente construída para confidencialidade e integridade: uma negociação IKE estabelece uma chave compartilhada, e a SA IPSec resultante criptografa e autentica o tráfego que corresponde a uma ACL definida. Funciona com endereços de par estáticos ou dinâmicos (modo agressivo), tolera NAT com NAT-T, e pode proteger tanto uma correspondência de ACL baseada em política quanto todo o tráfego de uma interface de túnel virtual. É a resposta padrão sempre que os dois extremos cruzam uma rede pública e os dados realmente importam — mas não é uma tecnologia de roteamento por si só: sem uma interface de túnel, protocolos de roteamento dinâmico não podem rodar sobre uma política IPSec como podem sobre GRE ou DSVPN, e é exatamente por isso que o IPSec é tão frequentemente combinado com um desses dois em vez de usado sozinho. Prós: criptografia e autenticação reais, travessia de NAT, funciona com endereços de par dinâmicos, templates de política permitem que um gateway hub aceite muitos pares de filiais sem configuração por filial. Contras: o IPSec baseado apenas em política não carrega um protocolo de roteamento, as definições de ACL em ambas as extremidades devem ser espelhadas exatamente, incompatibilidades de DPD e conjunto de cifras são as falhas de interoperabilidade mais comuns.

acl number 3101
 rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
#
ipsec proposal tran1
 esp authentication-algorithm sha2-256
#
ike proposal 1
 encryption-algorithm aes-cbc-128
 dh group14
 authentication-algorithm sha2-256
#
ike peer spub v1
 exchange-mode aggressive
 pre-shared-key cipher %^%#AbCd1234%^%#
 ike-proposal 1
 local-id-type name
 remote-name huawei02
 local-address 1.1.1.1
 remote-address 2.1.1.1
#
ipsec policy map1 10 isakmp
 security acl 3101
 ike-peer spub
 proposal tran1

BGP/MPLS IP VPN — o que a operadora executa, não o que você executa

Esta é a exceção nesta lista: BGP/MPLS IP VPN é o que o backbone de uma operadora executa para manter centenas de VPNs de clientes logicamente separadas sobre uma única rede MPLS compartilhada, usando route-distinguishers e route-targets para manter as rotas de cada cliente privadas enquanto uma única infraestrutura física carrega todas elas. Uma filial não implanta BGP/MPLS IP VPN por conta própria; ela se torna um roteador CE (customer edge) entregando rotas ao roteador PE (provider edge) da operadora, tipicamente via BGP, OSPF, rotas estáticas ou ISIS. Aparece nesta lista porque muitas conversas sobre "o que devemos usar para conectar nossas filiais" na verdade perguntam se devem construir IPSec/DSVPN sobre a internet pública, ou assinar um serviço MPLS L3VPN de uma operadora — e a resposta honesta é que essas opções resolvem orçamentos e modelos de confiança diferentes, não o mesmo problema com sintaxe diferente. Prós: separação e escala de nível operadora, não exige que o cliente gerencie criptografia ou estado de túnel, as opções de roteamento PE-CE são flexíveis. Contras: requer um relacionamento com uma operadora e acesso ao backbone MPLS, é um serviço que se compra em vez de infraestrutura que se constrói, projetos entre domínios ficam complexos rapidamente quando múltiplos ASes de operadoras estão envolvidos.

ip vpn-instance vpna
 ipv4-family
 route-distinguisher 100:1
 vpn-target 111:1 export-extcommunity
 vpn-target 111:1 import-extcommunity
#
mpls lsr-id 1.1.1.9
mpls
mpls ldp
#
interface Ethernet1/0/0
 ip binding vpn-instance vpna
 ip address 10.1.1.2 255.255.255.0
#
bgp 100
 peer 3.3.3.9 as-number 100
 peer 3.3.3.9 connect-interface LoopBack1
 ipv4-family vpnv4
 policy vpn-target
 peer 3.3.3.9 enable
 ipv4-family vpn-instance vpna
 peer 10.1.1.1 as-number 65410
 import-route direct

VLL — uma linha dedicada, reconstruída sobre MPLS

A Linha Dedicada Virtual (VLL estilo Martini) faz um trabalho específico: faz com que duas interfaces Ethernet (ou outra camada 2) em dois roteadores diferentes se comportem como se estivessem conectadas por um fio dedicado, tunelizadas por um núcleo MPLS via pseudo-fios sinalizados por LDP. Não há nenhuma decisão de roteamento IP envolvida — é uma interconexão cruzada de camada 2, e é exatamente por isso que é a ferramenta certa quando o roteamento próprio do cliente precisa permanecer totalmente intocado pela rede da operadora no meio. Não escala além de ponto a ponto: cada VLL conecta exatamente dois circuitos de acesso, então uma rede de muitas filiais precisa de muitas VLLs, não de uma VLL compartilhada. Prós: emulação de camada 2 totalmente transparente, o roteamento do cliente é invisível para o núcleo da operadora, pode rodar sobre um túnel GRE via tunnel-policy quando o núcleo não suporta MPLS nativo. Contras: estritamente ponto a ponto, sem criptografia, requer infraestrutura MPLS LDP de ponta a ponta (ou um substituto GRE).

mpls lsr-id 10.10.10.1
mpls
mpls l2vpn
mpls ldp
#
mpls ldp remote-peer 10.10.10.3
 remote-ip 10.10.10.3
#
interface GigabitEthernet1/0/0
 mpls l2vc 10.10.10.3 101

PWE3 — emulação de circuito para tráfego que não é IP de forma alguma

O PWE3 (Pseudo-Wire Emulation Edge-to-Edge) é no que o VLL se transforma quando o circuito transportado não é Ethernet de forma alguma — TDM, E1, ou outras interfaces legadas muito anteriores ao IP. O exemplo do qual esta nota parte é genuinamente de nicho, mas instrutivo: uma interface de rádio de voz legada do tipo E&M, transportada por um túnel MPLS TE com backup a quente e failover acionado por BFD, de modo que uma falha de enlace não produza nenhuma interrupção audível no tráfego transportado. Se uma filial tiver algum equipamento legado genuinamente não IP que precise continuar funcionando durante uma atualização da WAN, a emulação de circuito PWE3 é a tecnologia que permite que ele continue se comportando exatamente como sempre. Prós: transporta de forma transparente circuitos legados não IP, pode ser combinado com backup a quente MPLS TE e BFD para failover com perda quase nula. Contras: altamente especializado, apenas ponto a ponto, requer suporte de hardware/interface para o tipo específico de circuito legado, a maioria das redes corporativas de filiais nunca precisará dele.

interface Serial4/0/0
 link-protocol tdm
 em passthrough enable
 mpls l2vc pw-template pe2pe 300 tunnel-policy te
#
pw-template pe2pe
 peer-address 2.2.2.9
 jitter-buffer depth 8
 tdm-encapsulation-number 8
#
interface Tunnel1/0/0
 tunnel-protocol mpls te
 mpls te backup hot-standby mode revertive wtr 15

Cinco armadilhas na seleção

Cinco perguntas frequentes

Designs de soluções relacionadas

Leituras relacionadas