IPSec site a site via interface de túnel virtual: guia Huawei AR para Cisco
Um gateway de filial Huawei da série AR usando uma interface de túnel — não uma ACL — para transportar um caminho protegido por IPSec até um roteador Cisco na matriz: por que o VTI supera o IPSec baseado em políticas nesse caso, a configuração em seis etapas, e como confirmar que o túnel está realmente protegido.
Por Atlas Yuwen Zhang, fundador da AtlasCommTech — 18 anos em ICT, 13 deles em redes de operadoras · Atualizado em julho de 2026
Por que uma interface de túnel em vez de uma ACL
O emparelhamento de dois roteadores aqui é conhecido — a decisão real está em como o tráfego protegido é definido, não em como o túnel sobe.
A forma usual de construir um túnel IPSec entre uma filial e a matriz é com uma ACL: uma regra que enumera quais pares de sub-redes contam como «tráfego interessante» a ser criptografado. Isso funciona bem para um conjunto pequeno e fixo de sub-redes. Assim que uma filial fica grande o suficiente — muitas sub-redes, tráfego que continua crescendo, uma rede que continua mudando — a própria orientação da Huawei para esse emparelhamento recomenda mudar para uma interface de túnel virtual (VTI): o tráfego sob a interface de túnel recebe proteção IPSec automaticamente, sem nenhuma ACL definindo o que se qualifica.
Abaixo está a configuração na qual esta nota se baseia, por que o VTI se encaixa melhor assim que uma filial ultrapassa um punhado de sub-redes, e os seis problemas que aparecem com mais frequência quando uma interface de túnel — não uma ACL — é quem protege.
Topologia e plano de dados
Uma interface de túnel em cada lado — uma interface de camada 3 realmente roteável, não um gancho de política em uma porta física.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Endereçamento
| Item | RouterA — gateway Huawei da filial | RouterB — gateway Cisco da matriz |
|---|---|---|
| Endereço público (WAN) | 1.1.2.10 | 1.1.1.10 |
| Endereço da interface de túnel | 10.2.1.2 | 10.2.1.1 |
| Gateway da sub-rede privada | 10.1.1.1 | 10.1.2.1 |
Fase 1 — Parâmetros de negociação IKE
| Parâmetro | Valor (este exemplo) |
|---|---|
| Versão IKE | IKEv1 |
| Modo de negociação | Modo principal |
| Método de autenticação | Chave pré-compartilhada |
| Chave pré-compartilhada (este exemplo) | Ex@mpleKey26 — uma chave fictícia para este exemplo; defina sempre sua própria chave exclusiva. |
| Algoritmo de criptografia | aes-cbc-128 |
| Algoritmo de autenticação | sha1 |
| Grupo DH | group5 |
| DPD | Ativado |
Fase 2 — Parâmetros de negociação IPSec
| Parâmetro | Valor (este exemplo) |
|---|---|
| Protocolo de segurança | ESP |
| Modo de encapsulamento | Túnel |
| Algoritmo de criptografia | aes-128 |
| Algoritmo de autenticação | sha1 |
| Tempo de vida da SA | 3600 segundos (padrão) |
| PFS | Desativado |
VTI vs. IPSec baseado em ACL/política — o que realmente muda
A criptografia subjacente é a mesma; a resposta muda em «qual tráfego é protegido, e como isso se mantém sincronizado com a rede».
| Aspecto | IPSec baseado em ACL / política | Interface de túnel virtual (VTI) |
|---|---|---|
| O que define o tráfego protegido | Uma ACL enumerando pares de sub-redes origem/destino | Tudo o que for roteado para a interface de túnel |
| Adicionar uma nova sub-rede protegida | Adicionar ou editar uma regra de ACL e reaplicar a política | Adicionar uma rota — estática ou via protocolo de roteamento — para o túnel |
| Protocolos de roteamento dinâmico através do túnel | Não é suportado nativamente — não há interface para o OSPF ou BGP rodarem | Funciona diretamente — a interface de túnel é uma interface de camada 3 normal |
| Tráfego multicast | Precisa de soluções alternativas com GRE ou outro perfil | Funciona sobre o túnel como funcionaria em qualquer interface roteada |
| Melhor caso de uso | Um número pequeno e fixo de pares de sub-redes | Sites de filial grandes ou em crescimento, ou sites que já executam roteamento dinâmico |
Pontos-chave da configuração — lado Huawei
Seis etapas transformam uma interface de túnel simples em uma realmente protegida por IPSec.
- Configure os endereços IP das interfaces e uma rota estática para que os dois lados sejam alcançáveis pela rede pública.
- Crie a interface de túnel do tipo IPSec e aponte sua origem e destino para os dois endereços IP públicos.
- Opcional: execute um protocolo de roteamento dinâmico (OSPF, neste exemplo) sobre o túnel para que a sub-rede privada remota fique alcançável sem rotas estáticas — útil quando a sub-rede da filial é grande, e só possível porque o túnel é uma interface realmente roteável.
- Defina uma proposta IKE e um peer IKE — os atributos da fase 1: criptografia, autenticação, grupo DH, chave pré-compartilhada e DPD.
- Defina uma proposta IPSec (ESP, modo túnel, criptografia, autenticação) e um perfil IPSec que referencie tanto a proposta quanto o peer IKE.
- Aplique o perfil IPSec à interface de túnel para que ela realmente receba a proteção IPSec — esta é a etapa que transforma uma interface roteada em uma protegida.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] interface gigabitethernet 1/0/0
[RouterA-GigabitEthernet1/0/0] ip address 1.1.2.10 255.255.255.0
[RouterA-GigabitEthernet1/0/0] quit
[RouterA] interface gigabitethernet 2/0/0
[RouterA-GigabitEthernet2/0/0] ip address 10.1.1.1 255.255.255.0
[RouterA-GigabitEthernet2/0/0] quit
[RouterA] ip route-static 0.0.0.0 0.0.0.0 1.1.2.1
[RouterA] interface Tunnel0/0/0
[RouterA-Tunnel0/0/0] ip address 10.2.1.2 255.255.255.0
[RouterA-Tunnel0/0/0] tunnel-protocol ipsec
[RouterA-Tunnel0/0/0] source gigabitethernet 1/0/0
[RouterA-Tunnel0/0/0] destination 1.1.1.10
[RouterA-Tunnel0/0/0] quit
[RouterA] ospf 2
[RouterA-ospf-2] area 0.0.0.0
[RouterA-ospf-2-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[RouterA-ospf-2-area-0.0.0.0] network 10.2.1.0 0.0.0.255
[RouterA] ike proposal 5
[RouterA-ike-proposal-5] encryption-algorithm aes-cbc-128
[RouterA-ike-proposal-5] authentication-algorithm sha1
[RouterA-ike-proposal-5] dh group5
[RouterA-ike-proposal-5] authentication-method pre-share
[RouterA-ike-proposal-5] quit
[RouterA] ike peer RouterA v1
[RouterA-ike-peer-RouterA] ike-proposal 5
[RouterA-ike-peer-RouterA] pre-shared-key cipher Ex@mpleKey26
[RouterA-ike-peer-RouterA] dpd type periodic
[RouterA-ike-peer-RouterA] dpd msg seq-hash-notify
[RouterA-ike-peer-RouterA] quit
[RouterA] ipsec proposal RouterA
[RouterA-ipsec-proposal-RouterA] transform esp
[RouterA-ipsec-proposal-RouterA] encapsulation-mode tunnel
[RouterA-ipsec-proposal-RouterA] esp authentication-algorithm sha1
[RouterA-ipsec-proposal-RouterA] esp encryption-algorithm aes-128
[RouterA] ipsec profile profile1
[RouterA-ipsec-profile-profile1] ike-peer RouterA
[RouterA-ipsec-profile-profile1] proposal RouterA
[RouterA-ipsec-profile-profile1] quit
[RouterA] interface tunnel 0/0/0
[RouterA-Tunnel0/0/0] ipsec profile profile1Como isso fica do lado Cisco
Mesma lógica de interface de túnel, família de comandos diferente: uma interface de túnel em modo ipsec ipv4, crypto isakmp policy para os atributos da fase 1, crypto ipsec transform-set para os da fase 2, e um crypto ipsec profile vinculado à interface de túnel com tunnel protection ipsec profile — o equivalente Cisco de aplicar o perfil ipsec da Huawei em Tunnel0/0/0.
RouterB#configure
RouterB(config)#interface gigabitethernet 0/1
RouterB(config-if)#ip address 1.1.1.10 255.255.255.0
RouterB(config-if)#exit
RouterB(config)#interface gigabitethernet 0/2
RouterB(config-if)#ip address 10.1.2.1 255.255.255.0
RouterB(config-if)#exit
RouterB(config)#ip route 0.0.0.0 0.0.0.0 1.1.1.1
RouterB(config)#interface tunnel 0
RouterB(config-if)#ip address 10.2.1.1 255.255.255.0
RouterB(config-if)#tunnel mode ipsec ipv4
RouterB(config-if)#tunnel source gigabitethernet0/1
RouterB(config-if)#tunnel destination 1.1.2.10
RouterB(config-if)#exit
RouterB(config)#RouterB ospf 2
RouterB(config-RouterB)#network 10.2.1.0 0.0.0.255 area 0
RouterB(config-RouterB)#network 10.1.2.0 0.0.0.255 area 0
RouterB(config-RouterB)#exit
RouterB(config)#crypto isakmp policy 10
RouterB(config-isakmp)#hash sha
RouterB(config-isakmp)#encryption aes 128
RouterB(config-isakmp)#group 5
RouterB(config-isakmp)#authentication pre-share
RouterB(config-isakmp)#exit
RouterB(config)#crypto isakmp key Ex@mpleKey26 address 0.0.0.0 no-xauth
RouterB(config)#crypto isakmp keepalive 10 periodic
RouterB(config)#crypto ipsec transform-set tran1 esp-sha-hmac esp-aes 128
RouterB(cfg-crypto-trans)#mode tunnel
RouterB(cfg-crypto-trans)#exit
RouterB(config)#crypto ipsec profile profile1
RouterB(ipsec-profile)#set transform-set tran1
RouterB(ipsec-profile)#exit
RouterB(config)#interface tunnel 0
RouterB(config-if)#tunnel protection ipsec profile profile1
RouterB(config-if)#exitA sintaxe do lado Cisco desta nota foi verificada no Cisco IOS Software, C3900e-UNIVERSALK9-M, versão 15.2(4)M1 — IOS-XE e ASA usam sintaxe parecida, mas não idêntica.
6 armadilhas reais do método VTI
O primeiro é específico de construir IPSec sobre uma interface de túnel; os demais se aplicam a esse emparelhamento Huawei-Cisco qualquer que seja o método usado para subir o túnel.
1. Interface de túnel ativa não significa protegida
SINTOMAA interface Tunnel0/0/0 aparece ativa, e até os pings passam por ela — mas display ike sa não mostra nenhuma associação de segurança.
CAUSAAs etapas 2 a 5 constroem uma interface de túnel e um perfil IPSec como dois objetos separados. Nada os conecta até que a etapa 6 aplique explicitamente o perfil à interface. Até esse comando ser executado, a interface de túnel se comporta como qualquer outra interface roteável carregando tráfego em texto claro — «interface ativa» e «tráfego protegido» são dois fatos diferentes.
SOLUÇÃOConfirme que o perfil ipsec está aplicado na própria interface de túnel, não apenas definido como um objeto independente.
[RouterA] interface tunnel 0/0/0
[RouterA-Tunnel0/0/0] ipsec profile profile12. O formato dos pacotes DPD não coincide entre fabricantes
SINTOMAA detecção de peer inativo (DPD) está habilitada, e o túnel se comporta de forma imprevisível em vez de detectar corretamente um peer inativo.
CAUSAO formato de pacote DPD padrão da Cisco não é o mesmo do roteador Huawei. Deixado no padrão, o lado Huawei não está realmente falando o mesmo dialeto DPD que o lado Cisco.
SOLUÇÃONo roteador Huawei, defina o formato de mensagem DPD como seq-hash-notify para que corresponda ao que o lado Cisco espera.
[RouterA-ike-peer-RouterA] dpd type periodic
[RouterA-ike-peer-RouterA] dpd msg seq-hash-notify3. Os dois lados usam SHA-2: o túnel sobe, o tráfego não passa
SINTOMAdisplay ike sa (ou show crypto isakmp sa) mostra a fase 1 e a fase 2 estabelecidas, mas um ping através do túnel falha, ou só parte do tráfego passa.
CAUSAQuando o roteador Huawei e o dispositivo do outro fabricante usam um algoritmo SHA-2 na proposta de segurança IPSec, suas implementações de criptografia/decriptografia SHA-2 podem diferir o suficiente para que o túnel negocie bem, mas o plano de dados não.
SOLUÇÃONo roteador Huawei, habilite o modo de compatibilidade SHA-2 para que os dois lados processem o SHA-2 da mesma forma.
[RouterA] ipsec authentication sha2 compatible enable4. Origem do túnel configurada com IP dinâmico quebra na próxima troca de endereço
SINTOMAO túnel cai sem nenhuma mudança de configuração nos dois lados — geralmente logo depois que o IP público da filial muda em uma renovação DHCP ou PPPoE.
CAUSAA origem da interface de túnel foi configurada como um endereço IP fixo, mas esse endereço é atribuído dinamicamente na interface de saída. Quando o endereço muda, a origem configurada do túnel deixa de corresponder à realidade.
SOLUÇÃOConfigure source como a própria interface de saída, não seu endereço IP atual, para que o túnel acompanhe a interface em vez de uma foto do seu endereço.
[RouterA-Tunnel0/0/0] source gigabitethernet 1/0/05. A negociação de versão IKE não acontece como você esperava
SINTOMAO peer foi configurado esperando IKEv1 para combinar com uma configuração Cisco antiga, mas a negociação se comporta como IKEv2 — ou os dois lados simplesmente não concordam em uma versão.
CAUSAPor padrão, um peer IKE da Huawei tem tanto IKEv1 quanto IKEv2 habilitados. Ao iniciar a negociação, ele usa IKEv2; ao responder, suporta ambos. Precisar especificamente do IKEv1 precisa ser configurado explicitamente — isso não acontece automaticamente só porque o outro lado é um equipamento Cisco mais antigo.
SOLUÇÃODesabilite explicitamente o IKEv2 para que o peer apenas inicie e aceite IKEv1.
[RouterA-ike-peer-RouterA] version 1
[RouterA-ike-peer-RouterA] undo version 26. O comando copiado de um guia antigo não existe aqui
SINTOMAUm comando de um exemplo de configuração — remote-name, local-id-type name, ou um pre-shared-key simples — é rejeitado, ou se comporta de forma diferente, no equipamento à sua frente.
CAUSAA Huawei renomeou vários comandos de peer IKE entre versões de software. O comportamento funcional é o mesmo; a palavra-chave não.
SOLUÇÃOCombine a sintaxe com a versão de software realmente em execução antes de copiar uma linha de configuração.
| Sintaxe anterior | Sintaxe atual (verifique sua versão) |
|---|---|
| ike peer peer-name [ v1 | v2 ] | ike peer peer-name + version { 1 | 2 } (V200R008+) |
| remote-name | remote-id (V200R008+) |
| local-id-type name | local-id-type fqdn (V200R008+) |
| pre-shared-key key | pre-shared-key { simple | cipher } key (V200R003C00+) |
As palavras-chave dos comandos e os números de versão permanecem na forma original em todos os idiomas, para referência exata.
Projetos de soluções relacionadas
Como confirmar que está realmente funcionando
«Estabelecido» na tabela de SA é necessário, mas não suficiente — verifique também os contadores de pacotes.
- No roteador Huawei, execute display ike sa; no roteador Cisco, execute show crypto isakmp sa. As associações de segurança da fase 1 e da fase 2 devem aparecer como estabelecidas — a Huawei marca uma SA saudável como RD|ST (pronta, mantida ativa).
- display ipsec sa no roteador Huawei (show crypto ipsec sa no roteador Cisco) confirma o mesmo na camada IPSec.
- A partir de um host da filial, faça ping em um host da matriz através do túnel e depois execute display ipsec statistics esp no roteador Huawei. Os campos Inpacket decap count e Outpacket encap count devem ser diferentes de zero — isso confirma que o tráfego está realmente sendo criptografado e decriptografado, não apenas que a SA existe.
[RouterA] display ike sa
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------
8 1.1.1.10 0 RD|ST 2
6 1.1.1.10 0 RD|ST 1
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UPSe o túnel não se estabelecer de forma alguma, as duas primeiras coisas a verificar são sempre as mesmas: se a rota subjacente até o endereço público do peer é realmente alcançável, e se as configurações dos dois lados realmente coincidem, parâmetro por parâmetro.
Perguntas frequentes
As perguntas mais frequentes sobre esse emparelhamento VTI exato.
Ainda preciso de uma ACL em algum lugar num túnel IPSec baseado em VTI?
Não — esse é justamente o sentido da abordagem de interface de túnel virtual. Não há nenhuma ACL de seleção de tráfego; tudo o que a tabela de roteamento enviar para a interface de túnel recebe proteção IPSec. Ainda assim você precisa de uma rota normal, estática ou dinâmica, dizendo ao roteador para enviar esse tráfego para lá em primeiro lugar.
Posso rodar OSPF ou outro protocolo de roteamento dinâmico sobre esse túnel?
Sim. O próprio guia de configuração da Huawei para este exemplo exato mostra a execução do OSPF entre os dois endereços de interface de túnel para que a sub-rede privada remota fique alcançável sem rota estática — uma das vantagens práticas do VTI sobre o IPSec baseado em ACL, já que o túnel é uma interface de camada 3 roteável, não apenas um gancho de política em uma interface física.
O que acontece com o túnel se o IP público da filial mudar?
Se a origem da interface de túnel foi configurada como um endereço IP específico, o túnel quebra na próxima vez que esse endereço mudar — o que importa numa filial com IP público dinâmico via DHCP ou PPPoE. Configure source como a própria interface de saída, não uma foto do seu endereço — veja a Armadilha 4 acima.
O outro lado precisa ser um roteador Cisco para isso se aplicar?
Os parâmetros IKE e IPSec e a lógica da interface de túnel nesta nota são padrões neutros quanto ao fabricante; só muda a sintaxe de comandos do outro lado. Este guia foi verificado com um roteador Cisco. A Fortinet e outros fabricantes seguem a mesma lógica de fase 1 / fase 2 por um caminho de configuração diferente — veja nossa nota separada sobre Huawei para FortiGate para um exemplo baseado em política contra um firewall.
Vale a pena habilitar o PFS, já que este exemplo funciona sem ele?
O exemplo desta nota roda com o PFS desabilitado, seguindo a configuração de origem na qual se baseia. Habilitar o PFS adiciona uma nova troca Diffie-Hellman a cada renovação de chave da fase 2, o que resiste melhor a replays por comprometimento de chave a um pequeno custo de CPU — vale habilitar para segmentos de maior segurança, desde que os dois lados concordem com o mesmo grupo DH.
Limites honestos desta nota
Esta nota se baseia em uma configuração validada: um roteador Huawei (IKEv1, modo principal, chave pré-compartilhada, AES-128 / SHA-1) alcançando um roteador Cisco por uma interface de túnel virtual. O IPSec baseado em ACL/política, IKEv2, modo agressivo, travessia de NAT, e peers que não são Cisco — FortiGate, por exemplo, veja nossa nota complementar — mudam cada um os detalhes. Esta nota cobre o método VTI contra a Cisco, não todas as combinações.
Referências
Normas e documentos do fabricante em que esta nota se baseia. A sintaxe dos comandos segue a documentação do fabricante; verifique o comportamento exato na sua versão de firmware.
Envie-nos sua combinação exata
Modelos de equipamento, versões de software e se você está pendendo para VTI ou ACL — mande pelo WhatsApp e a gente ajuda a alinhar os parâmetros dos dois lados.