Por qué los terminales minoristas y las tiendas de sucursal necesitan dos enlaces de subida
Un terminal de autoservicio que pierde su VPN no solo pierde conectividad — pierde la capacidad de cobrar.
Una máquina expendedora, un quiosco de autoservicio o una pequeña sucursal minorista suele tener exactamente un enlace cableado, y cuando ese enlace falla — un cable cortado, una interrupción del ISP ascendente, un reinicio del router — el sitio queda a oscuras hasta que alguien se desplaza para repararlo. Para un terminal de autoservicio que maneja pagos y videovigilancia, ese tiempo de inactividad es directamente ingresos perdidos, y para una tienda en cadena es una escalada manual que no debería tener que ocurrir en absoluto. La solución en ambos casos industriales de los que parte esta nota es el mismo instinto con dos formas distintas: mantener siempre listo un segundo camino independiente, y conmutar a él automáticamente en el momento en que el camino principal deja de responder.
Esta nota presenta lado a lado dos implementaciones reales. La primera es una puerta de enlace de terminal de autoservicio con un enlace cableado principal y un respaldo celular 4G en el mismo dispositivo, conmutando automáticamente mediante detección de enlace basada en NQA. La segunda es un diseño de cadena de agencias donde las tiendas sucursales no tienen ningún enlace cableado — son puramente celulares (3G/LTE) — y el énfasis pasa de la conmutación por error a permitir que una sola puerta de enlace de sede sirva a decenas de pequeñas sucursales siempre inalámbricas mediante una plantilla de política IPSec. Ambos son patrones de VPN de doble enlace o multisucursal; no son el mismo problema.
Elementos esenciales de planificación
Decida estos cuatro aspectos antes de tocar la CLI.
Direccionamiento: el enlace cableado normalmente lleva una dirección privada o pública estable emitida por el ISP principal; el enlace celular lleva una dirección pública dinámica del operador móvil, por lo que cualquier configuración de par IKE en el lado celular debe tolerar una dirección que cambia entre reconexiones. Tráfico a proteger: ambos casos de esta nota protegen los mismos flujos de datos — VLAN de cámara/vigilancia y VLAN de terminal/transacción — sobre cualquiera que sea el enlace activo en ese momento, lo que significa que la ACL de seguridad debe ser idéntica en ambos túneles. Conjunto criptográfico: el caso del terminal de autoservicio en esta nota usa algoritmos criptográficos nacionales SM3/SM4 de extremo a extremo; esa elección es independiente del propio mecanismo de conmutación por error y puede sustituirse por AES/SHA-2 donde no se exija criptografía nacional. Objetivo de detección: la sonda NQA que decide si el enlace cableado está sano debe probar algo que solo sea alcanzable por el enlace cableado — probar un objetivo alcanzable desde ambos enlaces anula todo el mecanismo.
Detección y conmutación: NQA junto con standby track
La conmutación es un objeto track que vigila una sonda de salud, no una carrera de métricas de enrutamiento.
El mecanismo detrás de la conmutación automática es una instancia de prueba NQA (Network Quality Analysis) de Huawei que ejecuta una sonda ICMP por el enlace cableado hacia un objetivo que solo es alcanzable mientras el enlace cableado está sano — típicamente una dirección en la sede. Esa instancia de prueba está vinculada a un objeto track, y el objeto track está a su vez vinculado a la interfaz celular mediante standby track, lo que pone el enlace celular en estado de espera siempre que la sonda cableada esté sana, y lo activa en el momento en que la sonda falla. Dado que ambos enlaces ya cuentan con su propio túnel IPSec independiente y siempre establecido que protege el mismo tráfico definido por la ACL, la conmutación en sí es solo un cambio de estado de interfaz — no hay renegociación de IPSec ni espera de que se establezca un nuevo túnel, lo que mantiene corta la interrupción.
-- 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
Verificación: display standby state en la interfaz celular muestra STANDBY mientras la sonda cableada está sana, UP en el momento en que el enlace cableado falla, y vuelve a STANDBY una vez que el enlace cableado se recupera.
Puntos clave de configuración — terminal de autoservicio, dos túneles IPSec independientes
Una ACL, un conjunto de flujos protegidos, dos túneles negociados por separado.
Ambos enlaces de subida protegen el mismo tráfico de cámara y terminal con la misma ACL de seguridad, pero cada uno tiene su propio par IKE y su propia política IPSec vinculada a su propia interfaz — la interfaz GE cableada y la interfaz celular nunca comparten una única política IPSec. Este caso usa algoritmos criptográficos nacionales SM3/SM4 de principio a fin; sustituya los algoritmos de la propuesta por AES/SHA-2 si la criptografía nacional no es un requisito en su implementación.
-- 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
Dos casos de la industria, qué es realmente diferente
Una puerta de enlace con un enlace de respaldo no es el mismo problema de diseño que cincuenta puertas de enlace sin ningún enlace cableado.
El caso del terminal de autoservicio anterior es un problema de resiliencia: una sola puerta de enlace tiene dos enlaces de subida, y el objetivo es mantener el mismo sitio conectado cuando su camino normal falla. El caso de la cadena de agencias es un problema de escala: una puerta de enlace de sede (AR1220-S) necesita servir a decenas de pequeñas tiendas sucursales (AR101-S, AR121-S, AR207-S según el tamaño de la tienda), cada una puramente celular — no hay ningún enlace cableado que preferir, porque no hay ningún enlace cableado en absoluto. En lugar de una configuración de hub por sucursal, el lado de la sede ejecuta un ipsec policy-template con IKE en modo agresivo, de modo que cualquier sucursal que se presente con la clave precompartida correcta y el local-name correcto es aceptada sin que la sede necesite una entrada de par estática por tienda. Las sucursales se identifican por nombre (ike local-name / remote-name) en lugar de por dirección IP, porque la dirección pública de una sucursal celular cambia en cada reconexión. El NAT EasyIP en ambos extremos está configurado para excluir de la traducción el tráfico protegido por IPSec, de modo que la coincidencia de ACL propia del túnel no se rompa por la regla NAT que está delante de ella.
-- 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 | Enlaces de subida | Modo IKE | Identificación del par | Objetivo de diseño |
|---|---|---|---|---|
| Terminal de autoservicio | Cableado principal + respaldo 4G, una sola puerta de enlace | Modo principal / par estático por enlace | Dirección remota fija | Conmutación por error automática, disponibilidad continua de un solo sitio |
| Tiendas de cadena de agencias | Solo celular (3G/LTE), muchas puertas de enlace | Modo agresivo + plantilla de política | Basada en nombre (local-name / remote-name) | Escalar una política de sede a decenas de sucursales |
Cómo confirmar que realmente funciona
- Confirme que ambos túneles IPSec están establecidos de forma independiente antes de probar la conmutación por error — display ipsec sa debe mostrar una SA activa tanto en la interfaz cableada como en la celular al mismo tiempo.
- Compruebe directamente el resultado de la instancia de prueba NQA — display nqa results admin icmp debe mostrar éxito constante de la sonda mientras el enlace cableado esté sano.
- Confirme la vinculación de track con display standby state en la interfaz celular: STANDBY mientras el cableado esté sano.
- Desconecte o apague el enlace cableado y vuelva a comprobar display standby state — debe cambiar a UP dentro del intervalo de sonda configurado, sin interrupción de la SA de IPSec en el lado celular.
- Restaure el enlace cableado y confirme que el estado vuelve a STANDBY automáticamente, sin intervención manual.
Cuatro trampas de implementación
SÍNTOMAEl respaldo celular nunca se activa, incluso cuando el enlace cableado está caído
Se confirma que el enlace cableado está caído, pero display standby state sigue reportando STANDBY en la interfaz celular.
CAUSAEl objetivo de la sonda NQA es alcanzable por algún camino distinto del enlace cableado específico que se está monitoreando — por ejemplo, un objetivo alcanzable mediante una ruta predeterminada que en realidad no está vinculada a esa interfaz — por lo que la sonda sigue teniendo éxito incluso después de que falla el enlace cableado previsto.
SOLUCIÓNElija un destino NQA que solo sea alcanzable a través de la interfaz cableada monitoreada, y confirme con display nqa results que la sonda realmente falla cuando esa interfaz se desconecta.
SÍNTOMALa conmutación ocurre al instante, pero el tráfico sigue cayendo durante varios segundos
standby track pone la interfaz celular en UP justo a tiempo, pero el sitio sigue siendo inalcanzable durante un lapso notable después.
CAUSALa SA de IPSec del túnel celular nunca se mantuvo establecida de forma independiente — si el par IKE celular solo empieza a negociar después de que la interfaz se activa, el sitio queda inalcanzable durante todo el tiempo de negociación IKE/IPSec, no solo el intervalo de detección de la sonda.
SOLUCIÓNMantenga ambos túneles siempre activos, como en la configuración anterior — la conmutación debe ser un cambio de estado de interfaz de espera a activo, nunca una nueva negociación de IPSec.
SÍNTOMAEl túnel de una nueva tienda sucursal nunca se establece aunque la clave precompartida sea correcta
Se confirma que la IP celular de la sucursal funciona y la clave precompartida coincide, pero la negociación IKE con la sede sigue fallando.
CAUSAUn diseño de plantilla de política identifica a las sucursales por ike local-name / remote-name en modo agresivo, no por dirección IP. Si el local-name de la sucursal no coincide con lo que espera la sede, o la sucursal aún está configurada en modo principal en lugar de modo agresivo, la negociación falla sin importar que la clave sea correcta.
SOLUCIÓNVerifique que exchange-mode aggressive y local-id-type name estén configurados en la sucursal, y que el valor de local-name sea exactamente el que la configuración del policy-template de la sede espera para esa tienda.
SÍNTOMAEl túnel se establece, pero el tráfico protegido sigue siendo NATeado
Tanto las SA de IKE como de IPSec se muestran como establecidas, pero el tráfico hacia la sede llega con una dirección de origen traducida en lugar de la original.
CAUSALa regla NAT EasyIP en la interfaz saliente se evalúa sin una excepción para el destino protegido por IPSec, por lo que el tráfico que coincide con la ACL del túnel se traduce antes de llegar siquiera a la política IPSec.
SOLUCIÓNAñada una regla deny para el destino protegido por IPSec en la parte superior de la ACL de NAT outbound, exactamente como se muestra en la configuración de la sede anterior, para que el tráfico quede excluido de la traducción antes de llegar a la regla permit.
Preguntas frecuentes
¿El respaldo 4G reemplaza permanentemente el enlace cableado, o solo durante una interrupción?
Solo durante una interrupción. standby track es reversible por diseño — una vez que la sonda NQA sobre el enlace cableado vuelve a tener éxito, la interfaz celular vuelve automáticamente a espera, sin intervención manual.
¿El sitio necesita dos túneles VPN separados, o un túnel que migra entre enlaces de subida?
Dos túneles independientes y siempre establecidos — uno vinculado a la interfaz cableada, otro vinculado a la interfaz celular, ambos protegiendo el mismo tráfico definido por la ACL. La conmutación es un cambio de estado de interfaz, no una migración de túnel.
¿Puede una sucursal que solo es celular omitir por completo la planificación de doble enlace?
Sí — ese es exactamente el caso de la cadena de agencias en esta nota. No hay ningún camino cableado que preferir, por lo que no se necesita ningún mecanismo de conmutación NQA/track; la cuestión de diseño allí es escalar una puerta de enlace de sede a muchas sucursales, no la conmutación por error.
¿Cómo acepta la sede a decenas de tiendas sucursales sin una configuración estática por sucursal?
Un ipsec policy-template combinado con IKE en modo agresivo e identificación de par basada en nombre (local-name / remote-name) — cualquier sucursal que presente la clave precompartida correcta y el nombre de identidad correcto es aceptada a través de la plantilla sin una entrada de par dedicada.
¿Es obligatorio SM3/SM4, o se puede usar AES/SHA-2 estándar en su lugar?
SM3/SM4 es lo que usa el caso del terminal de autoservicio en esta nota porque los algoritmos criptográficos nacionales eran un requisito en esa implementación; el mecanismo de conmutación NQA/track y el mecanismo de escalado de policy-template funcionan de forma idéntica con AES/SHA-2 donde la criptografía nacional no es obligatoria.
Diseños de soluciones relacionadas
Red de tiendas minoristas y en cadena
El diseño completo de red de tiendas al que conduce este patrón de doble enlace y multisucursal, desde un solo quiosco hasta una cadena nacional.
Red de sucursales bancarias y financieras
Sucursales segmentadas, transporte SD-WAN de área amplia, redundancia de doble enlace y auditoría lista para el cumplimiento normativo en redes de sucursales reguladas.
¿Está planificando un despliegue de tiendas con resiliencia de doble enlace?
Cuéntenos cuántos sitios tiene, qué operadores están disponibles localmente, y si se requieren algoritmos criptográficos nacionales.