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 Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
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.
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) | huawei@123 — a chave do exemplo de origem; 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 |
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 |
Seis etapas transformam uma interface de túnel simples em uma realmente protegida por IPSec.
<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 huawei@123
[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 profile1Mesma 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 huawei@123 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.
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.
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 profile1SINTOMAA 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-notifySINTOMAdisplay 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 enableSINTOMAO 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/0SINTOMAO 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 2SINTOMAUm 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.
«Estabelecido» na tabela de SA é necessário, mas não suficiente — verifique também os contadores de pacotes.
[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.
As perguntas mais frequentes sobre esse emparelhamento VTI exato.
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.
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.
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.
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.
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.
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.
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.