Pourquoi les terminaux de vente au détail et les magasins d'agence ont besoin de deux liaisons montantes
Un terminal en libre-service qui perd son VPN ne perd pas seulement la connectivité — il perd la capacité d'encaisser un paiement.
Un distributeur automatique, une borne en libre-service ou une petite agence de vente au détail ne dispose généralement que d'une seule liaison filaire, et lorsque cette liaison tombe en panne — un câble sectionné, une panne du FAI en amont, un redémarrage du routeur — le site reste hors service jusqu'à ce que quelqu'un se déplace pour le réparer. Pour un terminal en libre-service traitant des paiements et de la surveillance, cette interruption représente directement du chiffre d'affaires, et pour une chaîne de magasins, c'est une escalade manuelle qui ne devrait pas avoir à se produire du tout. La solution dans les deux cas industriels dont s'inspire cette note repose sur le même instinct sous deux formes différentes : garder un second chemin indépendant toujours prêt, et y basculer automatiquement dès que le chemin principal cesse de répondre.
Cette note présente côte à côte deux déploiements réels. Le premier est une passerelle de terminal en libre-service avec une liaison filaire principale et un secours cellulaire 4G sur le même appareil, basculant automatiquement via une détection de liaison basée sur NQA. Le second est une conception de chaîne d'agences où les magasins n'ont aucune liaison filaire — ils sont purement cellulaires (3G/LTE) — et l'accent se déplace du basculement vers le fait de permettre à une seule passerelle de siège de servir des dizaines de petites agences toujours sans fil via un modèle de stratégie IPSec. Les deux sont des modèles de VPN à double liaison ou multi-agences ; ce n'est pas le même problème.
Éléments essentiels de planification
Décidez de ces quatre points avant de toucher à la CLI.
Adressage : la liaison filaire porte généralement une adresse privée ou publique stable attribuée par le FAI principal ; la liaison cellulaire porte une adresse publique dynamique de l'opérateur mobile, donc toute configuration de pair IKE côté cellulaire doit tolérer une adresse qui change à chaque reconnexion. Trafic à protéger : les deux cas de cette note protègent les mêmes flux de données — VLAN caméra/surveillance et VLAN terminal/transaction — quelle que soit la liaison actuellement active, ce qui signifie que l'ACL de sécurité doit être identique sur les deux tunnels. Suite cryptographique : le cas du terminal en libre-service dans cette note utilise des algorithmes cryptographiques nationaux SM3/SM4 de bout en bout ; ce choix est indépendant du mécanisme de basculement lui-même et peut être remplacé par AES/SHA-2 lorsque la cryptographie nationale n'est pas obligatoire. Cible de détection : la sonde NQA qui décide si la liaison filaire est saine doit tester quelque chose qui n'est joignable que via la liaison filaire — tester une cible joignable depuis les deux liaisons annule tout le mécanisme.
Détection et basculement : NQA et standby track
Le basculement est un objet track qui surveille une sonde de santé, pas une course de métriques de routage.
Le mécanisme derrière le basculement automatique est une instance de test NQA (Network Quality Analysis) de Huawei exécutant une sonde ICMP sur la liaison filaire vers une cible qui n'est joignable que lorsque la liaison filaire est saine — typiquement une adresse au siège. Cette instance de test est liée à un objet track, et l'objet track est à son tour lié à l'interface cellulaire via standby track, ce qui place la liaison cellulaire en état de veille tant que la sonde filaire est saine, et l'active dès que la sonde échoue. Comme les deux liaisons disposent déjà de leur propre tunnel IPSec indépendant et toujours établi protégeant le même trafic défini par l'ACL, le basculement lui-même n'est qu'un changement d'état d'interface — il n'y a ni renégociation IPSec ni attente de l'établissement d'un nouveau tunnel, ce qui maintient l'interruption courte.
-- 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
Vérification : display standby state sur l'interface cellulaire indique STANDBY tant que la sonde filaire est saine, UP dès que la liaison filaire échoue, et revient à STANDBY une fois la liaison filaire rétablie.
Points clés de configuration — terminal en libre-service, deux tunnels IPSec indépendants
Une ACL, un ensemble de flux protégés, deux tunnels négociés séparément.
Les deux liaisons montantes protègent le même trafic caméra et terminal avec la même ACL de sécurité, mais chacune possède son propre pair IKE et sa propre stratégie IPSec liée à sa propre interface — l'interface GE filaire et l'interface cellulaire ne partagent jamais une seule stratégie IPSec. Ce cas utilise des algorithmes cryptographiques nationaux SM3/SM4 de bout en bout ; remplacez les algorithmes de la proposition par AES/SHA-2 si la cryptographie nationale n'est pas une exigence de votre déploiement.
-- 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
Deux cas industriels, ce qui diffère réellement
Une passerelle avec une liaison de secours n'est pas le même problème de conception que cinquante passerelles sans aucune liaison filaire.
Le cas du terminal en libre-service ci-dessus est un problème de résilience : une seule passerelle possède deux liaisons montantes, et l'objectif est de maintenir le même site connecté lorsque son chemin normal échoue. Le cas de la chaîne d'agences est un problème d'échelle : une passerelle de siège (AR1220-S) doit servir des dizaines de petits magasins d'agence (AR101-S, AR121-S, AR207-S selon la taille du magasin), chacun étant purement cellulaire — il n'y a aucune liaison filaire à privilégier, car il n'y a aucune liaison filaire du tout. Au lieu d'une configuration de hub par agence, le côté siège exécute un ipsec policy-template avec IKE en mode agressif, de sorte que toute agence se présentant avec la bonne clé pré-partagée et le bon local-name est acceptée sans que le siège n'ait besoin d'une entrée de pair statique par magasin. Les agences s'identifient par nom (ike local-name / remote-name) plutôt que par adresse IP, car l'adresse publique d'une agence cellulaire change à chaque reconnexion. Le NAT EasyIP des deux côtés est configuré pour exclure le trafic protégé par IPSec de la traduction, afin que la correspondance ACL propre du tunnel ne soit pas rompue par la règle NAT qui la précède.
-- 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
| Cas | Liaisons montantes | Mode IKE | Identification du pair | Objectif de conception |
|---|---|---|---|---|
| Terminal en libre-service | Filaire principal + secours 4G, une seule passerelle | Mode principal / pair statique par liaison | Adresse distante fixe | Basculement automatique, disponibilité continue d'un site unique |
| Magasins de chaîne d'agences | Cellulaire (3G/LTE) uniquement, nombreuses passerelles | Mode agressif + modèle de stratégie | Basée sur le nom (local-name / remote-name) | Étendre une stratégie de siège à des dizaines d'agences |
Comment confirmer que cela fonctionne réellement
- Confirmez que les deux tunnels IPSec sont établis indépendamment avant de tester le basculement — display ipsec sa doit afficher une SA active à la fois sur l'interface filaire et sur l'interface cellulaire.
- Vérifiez directement le résultat de l'instance de test NQA — display nqa results admin icmp doit montrer un succès constant de la sonde tant que la liaison filaire est saine.
- Confirmez la liaison track avec display standby state sur l'interface cellulaire : STANDBY tant que le filaire est sain.
- Déconnectez ou arrêtez la liaison filaire et revérifiez display standby state — elle doit passer à UP dans l'intervalle de sonde configuré, sans interruption de la SA IPSec côté cellulaire.
- Rétablissez la liaison filaire et confirmez que l'état revient automatiquement à STANDBY, sans intervention manuelle.
Quatre pièges de déploiement
SYMPTÔMELe secours cellulaire ne s'active jamais, même quand la liaison filaire est coupée
La liaison filaire est confirmée hors service, mais display standby state continue d'indiquer STANDBY sur l'interface cellulaire.
CAUSELa cible de la sonde NQA est joignable par un autre chemin que la liaison filaire spécifique surveillée — par exemple, une cible joignable via une route par défaut qui n'est pas réellement liée à cette interface — de sorte que la sonde continue de réussir même après l'échec de la liaison filaire visée.
CORRECTIFChoisissez une destination NQA qui n'est joignable que via l'interface filaire surveillée, et confirmez avec display nqa results que la sonde échoue réellement lorsque cette interface est déconnectée.
SYMPTÔMELe basculement se produit instantanément, mais le trafic chute encore pendant plusieurs secondes
standby track fait passer l'interface cellulaire à UP exactement au moment prévu, mais le site reste inaccessible pendant un intervalle notable ensuite.
CAUSELa SA IPSec du tunnel cellulaire n'a jamais été maintenue établie indépendamment — si le pair IKE cellulaire ne commence à négocier qu'après le passage de l'interface à UP, le site est inaccessible pendant toute la durée de la négociation IKE/IPSec, pas seulement l'intervalle de détection de la sonde.
CORRECTIFGardez les deux tunnels toujours actifs, comme dans la configuration ci-dessus — le basculement doit être un changement d'état d'interface de veille à actif, jamais une nouvelle négociation IPSec.
SYMPTÔMELe tunnel d'un nouveau magasin d'agence ne se monte jamais malgré une clé pré-partagée correcte
L'IP cellulaire de l'agence est confirmée fonctionnelle et la clé pré-partagée correspond, mais la négociation IKE avec le siège échoue encore.
CAUSEUne conception à modèle de stratégie identifie les agences par ike local-name / remote-name en mode agressif, pas par adresse IP. Si le local-name de l'agence ne correspond pas à ce qu'attend le siège, ou si l'agence est encore configurée en mode principal au lieu du mode agressif, la négociation échoue quelle que soit la clé correcte.
CORRECTIFVérifiez que exchange-mode aggressive et local-id-type name sont définis sur l'agence, et que la valeur de local-name correspond exactement à ce que la configuration du policy-template du siège attend pour ce magasin.
SYMPTÔMELe tunnel se monte, mais le trafic protégé subit toujours une traduction NAT
Les SA IKE et IPSec s'affichent toutes deux comme établies, mais le trafic vers le siège arrive avec une adresse source traduite au lieu de l'originale.
CAUSELa règle NAT EasyIP sur l'interface sortante est évaluée sans exception pour la destination protégée par IPSec, de sorte que le trafic correspondant à l'ACL du tunnel est traduit avant même d'atteindre la stratégie IPSec.
CORRECTIFAjoutez une règle deny pour la destination protégée par IPSec en haut de l'ACL du NAT outbound, exactement comme indiqué dans la configuration du siège ci-dessus, afin que le trafic soit exclu de la traduction avant d'atteindre la règle permit.
Questions fréquentes
Le secours 4G remplace-t-il définitivement la liaison filaire, ou seulement pendant une panne ?
Seulement pendant une panne. standby track est conçu pour être réversible — dès que la sonde NQA sur la liaison filaire réussit à nouveau, l'interface cellulaire revient automatiquement en veille, sans intervention manuelle.
Le site a-t-il besoin de deux tunnels VPN séparés, ou d'un seul tunnel qui migre entre les liaisons montantes ?
Deux tunnels indépendants et toujours établis — l'un lié à l'interface filaire, l'autre à l'interface cellulaire, tous deux protégeant le même trafic défini par l'ACL. Le basculement est un changement d'état d'interface, pas une migration de tunnel.
Une agence entièrement cellulaire peut-elle complètement ignorer la planification à double liaison ?
Oui — c'est exactement le cas de la chaîne d'agences dans cette note. Il n'y a aucune liaison filaire à privilégier, donc aucun mécanisme de basculement NQA/track n'est nécessaire ; la question de conception là-bas est d'étendre une passerelle de siège à de nombreuses agences, pas le basculement.
Comment le siège accepte-t-il des dizaines de magasins d'agence sans configuration statique par agence ?
Un ipsec policy-template combiné à IKE en mode agressif et à une identification de pair basée sur le nom (local-name / remote-name) — toute agence présentant la bonne clé pré-partagée et le bon nom d'identité est acceptée via le modèle sans entrée de pair dédiée.
SM3/SM4 est-il obligatoire, ou peut-on utiliser AES/SHA-2 standard à la place ?
SM3/SM4 est ce qu'utilise le cas du terminal en libre-service dans cette note car les algorithmes cryptographiques nationaux étaient une exigence de ce déploiement ; le mécanisme de basculement NQA/track et le mécanisme de mise à l'échelle du policy-template fonctionnent tous deux à l'identique avec AES/SHA-2 lorsque la cryptographie nationale n'est pas obligatoire.
Conceptions de solutions associées
Réseau de magasins de détail et de chaîne
La conception complète du réseau de magasins vers laquelle mène ce modèle à double liaison et multi-agences, d'un simple kiosque à une chaîne nationale.
Réseau d'agences bancaires et financières
Agences segmentées, transport SD-WAN sur grande distance, redondance à double liaison et audit prêt pour la conformité pour les réseaux d'agences réglementés.
Vous planifiez un déploiement de magasins avec résilience à double liaison ?
Dites-nous combien de sites, quels opérateurs sont disponibles localement, et si des algorithmes cryptographiques nationaux sont requis.