Por que terminais de varejo e lojas de filial precisam de dois uplinks
Um terminal de autoatendimento que perde sua VPN não perde apenas conectividade — perde a capacidade de receber pagamentos.
Uma máquina de vendas, um quiosque de autoatendimento ou uma pequena filial de varejo geralmente tem exatamente um enlace cabeado, e quando esse enlace falha — um cabo cortado, uma interrupção do ISP upstream, uma reinicialização do roteador — o site fica sem conexão até que alguém vá até o local para consertar. Para um terminal de autoatendimento que lida com pagamentos e vigilância, esse tempo de inatividade é diretamente receita perdida, e para uma rede de lojas é uma escalada manual que não deveria precisar acontecer. A solução em ambos os casos setoriais dos quais esta nota parte é o mesmo instinto sob duas formas diferentes: manter sempre pronto um segundo caminho independente, e comutar para ele automaticamente no momento em que o caminho principal para de responder.
Esta nota apresenta lado a lado duas implantações reais. A primeira é um gateway de terminal de autoatendimento com um enlace cabeado principal e um backup celular 4G no mesmo dispositivo, comutando automaticamente via detecção de enlace baseada em NQA. A segunda é um design de rede de agências onde as lojas filiais não têm nenhum enlace cabeado — são puramente celulares (3G/LTE) — e a ênfase muda de failover para permitir que um único gateway de matriz atenda dezenas de pequenas filiais sempre sem fio por meio de um template de política IPSec. Ambos são padrões de VPN de enlace duplo ou multi-filial; não são o mesmo problema.
Elementos essenciais de planejamento
Decida estas quatro coisas antes de mexer na CLI.
Endereçamento: o enlace cabeado geralmente carrega um endereço privado ou público estável emitido pelo ISP principal; o enlace celular carrega um endereço público dinâmico da operadora móvel, então qualquer configuração de par IKE no lado celular precisa tolerar um endereço que muda a cada reconexão. Tráfego a proteger: ambos os casos nesta nota protegem os mesmos fluxos de dados — VLANs de câmera/vigilância e VLANs de terminal/transação — seja qual for o enlace ativo no momento, o que significa que a ACL de segurança precisa ser idêntica em ambos os túneis. Conjunto criptográfico: o caso do terminal de autoatendimento nesta nota usa algoritmos criptográficos nacionais SM3/SM4 de ponta a ponta; essa escolha é independente do próprio mecanismo de failover e pode ser trocada por AES/SHA-2 onde a criptografia nacional não for obrigatória. Alvo de detecção: a sondagem NQA que decide se o enlace cabeado está saudável precisa testar algo que só seja alcançável pelo enlace cabeado — testar um alvo alcançável por ambos os enlaces anula todo o mecanismo.
Detecção e comutação: NQA com standby track
A comutação é um objeto track observando uma sondagem de saúde, não uma disputa de métricas de roteamento.
O mecanismo por trás do failover automático é uma instância de teste NQA (Network Quality Analysis) da Huawei executando uma sondagem ICMP pelo enlace cabeado até um alvo que só é alcançável enquanto o enlace cabeado está saudável — normalmente um endereço na matriz. Essa instância de teste está vinculada a um objeto track, e o objeto track por sua vez está vinculado à interface celular via standby track, o que coloca o enlace celular em estado de espera sempre que a sondagem cabeada está saudável, e o ativa no momento em que a sondagem falha. Como ambos os enlaces já têm seu próprio túnel IPSec independente e sempre estabelecido protegendo o mesmo tráfego definido pela ACL, a comutação em si é apenas uma mudança de estado de interface — não há renegociação de IPSec nem espera pelo estabelecimento de um novo túnel, o que mantém a interrupção curta.
-- NQA probe over the wired path -- nqa test-instance admin icmp test-type icmp destination-address ipv4 192.168.100.1 frequency 5 probe-count 3 timeout 1 start now # -- Cellular interface follows the probe via track -- interface Cellular0/0/0 standby track nqa admin icmp
Verificação: display standby state na interface celular mostra STANDBY enquanto a sondagem cabeada está saudável, UP no momento em que o enlace cabeado falha, e retorna a STANDBY assim que o enlace cabeado se recupera.
Destaques de configuração — terminal de autoatendimento, dois túneis IPSec independentes
Uma ACL, um conjunto de fluxos protegidos, dois túneis negociados separadamente.
Ambos os enlaces de subida protegem o mesmo tráfego de câmera e terminal com a mesma ACL de segurança, mas cada um tem seu próprio par IKE e sua própria política IPSec vinculada à sua própria interface — a interface GE cabeada e a interface celular nunca compartilham uma única política IPSec. Este caso usa algoritmos criptográficos nacionais SM3/SM4 do início ao fim; troque os algoritmos da proposta por AES/SHA-2 se a criptografia nacional não for um requisito na sua implantação.
-- Shared protected-traffic definition -- acl number 3000 rule 5 permit ip source 10.168.11.0 0.0.0.255 destination 192.168.100.0 0.0.0.255 rule 10 permit ip source 10.168.12.0 0.0.0.255 destination 192.168.100.0 0.0.0.255 # ipsec proposal prop1 esp authentication-algorithm sm3 esp encryption-algorithm sm4 # ike proposal 1 encryption-algorithm sm4 dh group14 authentication-algorithm sm3 -- Tunnel 1: wired uplink -- ike peer hq_wired pre-shared-key cipher %^%#AbCd1234%^%# ike-proposal 1 local-address 10.100.2.1 remote-address 202.1.1.1 # ipsec policy wired_policy 10 isakmp security acl 3000 ike-peer hq_wired proposal prop1 # interface GigabitEthernet0/0/4 ip address 10.100.2.1 255.255.255.0 ipsec policy wired_policy -- Tunnel 2: cellular uplink, independent peer and policy -- ike peer hq_cell pre-shared-key cipher %^%#AbCd1234%^%# ike-proposal 1 remote-address 202.1.1.1 # ipsec policy cell_policy 10 isakmp security acl 3000 ike-peer hq_cell proposal prop1 # interface Cellular0/0/0 ipsec policy cell_policy standby track nqa admin icmp
Dois casos setoriais, o que realmente é diferente
Um gateway com um enlace de backup não é o mesmo problema de design que cinquenta gateways sem nenhum enlace cabeado.
O caso do terminal de autoatendimento acima é um problema de resiliência: um único gateway tem dois enlaces de subida, e o objetivo é manter o mesmo site conectado quando seu caminho normal falha. O caso da rede de agências é um problema de escala: um gateway de matriz (AR1220-S) precisa atender dezenas de pequenas lojas filiais (AR101-S, AR121-S, AR207-S dependendo do tamanho da loja), cada uma puramente celular — não há nenhum enlace cabeado a preferir, porque não há nenhum enlace cabeado. Em vez de uma configuração de hub por filial, o lado da matriz executa um ipsec policy-template com IKE em modo agressivo, de modo que qualquer filial que apareça com a chave pré-compartilhada correta e o local-name correto é aceita sem que a matriz precise de uma entrada de par estática por loja. As filiais se identificam por nome (ike local-name / remote-name) em vez de por endereço IP, porque o endereço público de uma filial celular muda a cada reconexão. O NAT EasyIP em ambas as extremidades é configurado para excluir da tradução o tráfego protegido por IPSec, de modo que a correspondência de ACL do próprio túnel não seja quebrada pela regra de NAT posicionada à frente dela.
-- HQ side: one policy-template serves many branches -- acl number 3001 rule 5 permit ip source any destination 192.168.100.0 0.0.0.255 # ipsec proposal prop2 esp authentication-algorithm sha2-256 esp encryption-algorithm aes-256 # ike proposal 2 encryption-algorithm aes-cbc-256 authentication-algorithm sha2-256 dh group14 # ike peer branch_tmpl exchange-mode aggressive pre-shared-key cipher %^%#AbCd1234%^%# ike-proposal 2 local-id-type name local-name hq_hub # ipsec policy-template tmpl1 10 security acl 3001 ike-peer branch_tmpl proposal prop2 # ipsec policy branch_policy 10 isakmp template tmpl1 # interface GigabitEthernet0/0/1 ip address 202.1.1.1 255.255.255.0 ipsec policy branch_policy nat outbound 2000 # acl number 2000 rule 5 deny ip destination 192.168.100.0 0.0.0.255 rule 10 permit ip source any -- Branch side: cellular-only store, name-based identification -- ike peer hq exchange-mode aggressive pre-shared-key cipher %^%#AbCd1234%^%# ike-proposal 2 local-id-type name local-name store001 remote-address 202.1.1.1 # ipsec policy store_policy 10 isakmp security acl 3002 ike-peer hq proposal prop2 # interface Cellular0/0/0 ipsec policy store_policy nat outbound 2001
| Caso | Uplinks | Modo IKE | Identificação do par | Objetivo de design |
|---|---|---|---|---|
| Terminal de autoatendimento | Cabeado principal + backup 4G, um único gateway | Modo principal / par estático por uplink | Endereço remoto fixo | Failover automático, disponibilidade contínua de um único site |
| Lojas de rede de agências | Somente celular (3G/LTE), muitos gateways | Modo agressivo + template de política | Baseada em nome (local-name / remote-name) | Escalar uma política de matriz para dezenas de filiais |
Como confirmar que está realmente funcionando
- Confirme que ambos os túneis IPSec estão estabelecidos de forma independente antes de testar o failover — display ipsec sa deve mostrar uma SA ativa tanto na interface cabeada quanto na celular ao mesmo tempo.
- Verifique diretamente o resultado da instância de teste NQA — display nqa results admin icmp deve mostrar sucesso consistente da sondagem enquanto o enlace cabeado estiver saudável.
- Confirme a vinculação do track com display standby state na interface celular: STANDBY enquanto o cabeado estiver saudável.
- Desconecte ou desligue o enlace cabeado e verifique novamente display standby state — deve mudar para UP dentro do intervalo de sondagem configurado, sem interrupção da SA IPSec no lado celular.
- Restaure o enlace cabeado e confirme que o estado retorna a STANDBY automaticamente, sem intervenção manual.
Quatro armadilhas de implantação
SINTOMAO backup celular nunca ativa, mesmo com o enlace cabeado fora do ar
O enlace cabeado é confirmado como inativo, mas display standby state continua reportando STANDBY na interface celular.
CAUSAO alvo da sondagem NQA é alcançável por algum caminho diferente do enlace cabeado específico monitorado — por exemplo, um alvo alcançável por uma rota padrão que não está realmente vinculada a essa interface — então a sondagem continua tendo sucesso mesmo depois que o enlace cabeado pretendido falha.
SOLUÇÃOEscolha um destino NQA que só seja alcançável pela interface cabeada monitorada, e confirme com display nqa results que a sondagem realmente falha quando essa interface é desconectada.
SINTOMAO failover acontece instantaneamente, mas o tráfego ainda cai por vários segundos
O standby track muda a interface celular para UP no momento certo, mas o site ainda fica inacessível por um intervalo perceptível depois.
CAUSAA SA IPSec do túnel celular nunca foi mantida estabelecida de forma independente — se o par IKE celular só começa a negociar depois que a interface sobe, o site fica inacessível durante todo o tempo de negociação IKE/IPSec, não apenas o intervalo de detecção da sondagem.
SOLUÇÃOMantenha ambos os túneis sempre ativos, como na configuração acima — a comutação deve ser uma mudança de estado de interface de standby para ativo, nunca uma nova negociação IPSec.
SINTOMAO túnel de uma nova loja filial nunca sobe mesmo com a chave pré-compartilhada correta
O IP celular da filial é confirmado como funcional e a chave pré-compartilhada corresponde, mas a negociação IKE com a matriz ainda falha.
CAUSAUm design de template de política identifica filiais por ike local-name / remote-name em modo agressivo, não por endereço IP. Se o local-name da filial não corresponder ao que a matriz espera, ou a filial ainda estiver configurada para modo principal em vez de modo agressivo, a negociação falha independentemente de a chave estar correta.
SOLUÇÃOVerifique se exchange-mode aggressive e local-id-type name estão configurados na filial, e se o valor de local-name é exatamente o que a configuração do policy-template da matriz espera para essa loja.
SINTOMAO túnel sobe, mas o tráfego protegido ainda sofre NAT
Tanto as SAs IKE quanto IPSec aparecem como estabelecidas, mas o tráfego para a matriz chega com um endereço de origem traduzido em vez do original.
CAUSAA regra de NAT EasyIP na interface de saída é avaliada sem uma exceção para o destino protegido por IPSec, então o tráfego que corresponde à ACL do túnel é traduzido antes mesmo de chegar à política IPSec.
SOLUÇÃOAdicione uma regra deny para o destino protegido por IPSec no topo da ACL de NAT outbound, exatamente como mostrado na configuração da matriz acima, para que o tráfego seja excluído da tradução antes de chegar à regra permit.
Perguntas frequentes
O backup 4G substitui permanentemente o enlace cabeado, ou apenas durante uma interrupção?
Apenas durante uma interrupção. O standby track é reversível por design — assim que a sondagem NQA pelo enlace cabeado tem sucesso novamente, a interface celular retorna automaticamente ao standby, sem intervenção manual.
O site precisa de dois túneis VPN separados, ou um túnel que migra entre uplinks?
Dois túneis independentes e sempre estabelecidos — um vinculado à interface cabeada, outro vinculado à interface celular, ambos protegendo o mesmo tráfego definido pela ACL. A comutação é uma mudança de estado de interface, não uma migração de túnel.
Uma filial totalmente celular pode pular completamente o planejamento de enlace duplo?
Sim — esse é exatamente o caso da rede de agências nesta nota. Não há nenhum caminho cabeado a preferir, então não é necessário nenhum mecanismo de failover NQA/track; a questão de design ali é escalar um gateway de matriz para muitas filiais, não failover.
Como a matriz aceita dezenas de lojas filiais sem uma configuração estática por filial?
Um ipsec policy-template combinado com IKE em modo agressivo e identificação de par baseada em nome (local-name / remote-name) — qualquer filial que apresente a chave pré-compartilhada correta e o nome de identidade correto é aceita através do template sem uma entrada de par dedicada.
O SM3/SM4 é obrigatório, ou pode-se usar AES/SHA-2 padrão em vez disso?
SM3/SM4 é o que o caso do terminal de autoatendimento nesta nota usa porque algoritmos criptográficos nacionais eram um requisito naquela implantação; o mecanismo de failover NQA/track e o mecanismo de escala do policy-template funcionam de forma idêntica com AES/SHA-2 onde a criptografia nacional não é obrigatória.
Designs de soluções relacionadas
Rede de varejo e lojas em cadeia
O design completo de rede de lojas para o qual este padrão de enlace duplo e multi-filial leva, de um único quiosque a uma rede nacional.
Rede de filiais bancárias e financeiras
Filiais segmentadas, transporte SD-WAN de longa distância, redundância de enlace duplo e auditoria pronta para conformidade em redes de filiais regulamentadas.
Está planejando uma implantação de lojas com resiliência de enlace duplo?
Diga-nos quantos sites você tem, quais operadoras estão disponíveis localmente, e se algoritmos criptográficos nacionais são necessários.