Distributeurs de billets et OpenVPN : que se passe-t-il en cas de panne WAN ?

Un distributeur automatique de billets peut retrouver son accès à Internet avant de pouvoir traiter la transaction suivante. Lorsqu’une liaison filaire tombe en panne, le passage au réseau cellulaire rétablit le chemin réseau sous-jacent. Le tunnel OpenVPN doit encore se reconnecter, et l’application transactionnelle doit reprendre son fonctionnement.
Cette succession d’étapes explique pourquoi le basculement WAN, le rétablissement du VPN et la reprise de l’application doivent être envisagés ensemble. Cet article suit le chemin d’un distributeur automatique distant jusqu’aux systèmes de traitement du centre de données, y compris lorsque la connexion est partagée avec des caméras ou d’autres équipements du site.
La liaison filaire tombe. Que se passe-t-il ensuite ?
Prenons un site où un distributeur automatique et un enregistreur vidéo partagent une connexion Internet filaire. Le distributeur dispose de son propre segment réseau, tandis que l’enregistreur transmet des vidéos en arrière-plan. Le routeur contient également deux cartes SIM de différents opérateurs.
Si la liaison filaire tombe en panne, le routeur détecte la défaillance et bascule vers la première connexion cellulaire. Il dispose alors d’un autre accès à Internet. Cela ne prouve pas, à lui seul, que le distributeur peut joindre le système de traitement des transactions.
Le client OpenVPN doit établir son tunnel sur le nouveau chemin. Le serveur authentifie le routeur, puis les routes configurées acheminent le trafic du distributeur vers les systèmes de traitement situés derrière ce serveur. L’application peut alors tenter un nouvel échange. Le délai de réussite dépend du rétablissement du réseau et du comportement propre à l’application.
Si le premier opérateur devient ensuite indisponible, le passage à la seconde carte SIM lance une nouvelle séquence de reprise. Un second opérateur offre un chemin alternatif lorsque son service est disponible ; le basculement doit néanmoins être testé. Sur les sites sans liaison fixe, le même raisonnement s’applique au réseau cellulaire utilisé comme connexion principale.
Ces distinctions sont utiles pour analyser une panne : un WAN actif, un VPN connecté et une transaction réussie sont trois observations différentes.
Pourquoi le routeur initie le tunnel
Le distributeur se connecte au routeur du site par Ethernet. Le routeur joue le rôle de client OpenVPN et initie une connexion vers un serveur OpenVPN joignable dans le centre de données. Les systèmes de traitement des transactions se trouvent derrière ce serveur.

Ce sens de connexion est utile sur les réseaux cellulaires, où un opérateur peut placer la SIM derrière une traduction d’adresses et limiter les connexions entrantes. Cette architecture ne nécessite pas d’adresse publique joignable en entrée sur le site. Elle nécessite un chemin sortant vers l’adresse et le port configurés du serveur.
Lors d’un changement de WAN, l’adresse externe du routeur peut également changer. Son certificat client continue de l’identifier auprès du serveur. Une adresse de tunnel fixe, attribuée dans la configuration du serveur propre à chaque client, peut maintenir la cohérence de l’adressage du site et des règles de pare-feu lors des reconnexions.
Le manuel OpenVPN décrit les mécanismes qui aident le client à rétablir la connexion :
Les paramètres keepalive et de redémarrage détectent un pair qui ne répond plus et déclenchent une reconnexion après le délai configuré.
Les paramètres persist peuvent conserver l’interface du tunnel lors des redémarrages pris en charge. Ils ne maintiennent pas la circulation des paquets lorsque la connexion sous-jacente est indisponible.
Les nouvelles tentatives de résolution de noms permettent au client de poursuivre ses essais pendant le retour de l’accès réseau.
Plusieurs entrées `remote` fournissent des points de terminaison serveur alternatifs si le premier est injoignable.
Les paramètres disponibles dépendent du micrologiciel du routeur et de la configuration du serveur. Leur objectif est de rendre la reprise suffisamment prévisible pour être testée sur le site réel.
Séparer le chemin du distributeur des autres flux du site
Un distributeur peut partager son routeur avec une centrale d’alarme, des caméras, un affichage numérique, un terminal de point de vente ou le Wi-Fi du personnel. Le rétablissement du WAN ne doit pas donner à tous ces équipements accès au réseau de traitement.
Placez le distributeur dans son propre VLAN et sous-réseau, puis définissez les destinations accessibles à ce sous-réseau. Les VLAN séparent les segments réseau ; les règles de routage et de pare-feu contrôlent les accès entre eux. Le sous-réseau du distributeur peut être acheminé par OpenVPN vers les hôtes et ports de traitement requis. Selon leur fonction, les autres équipements peuvent utiliser un accès Internet local, un tunnel séparé ou un chemin restreint.
Attribuez à chaque site un sous-réseau de distributeur distinct, issu d’un plan d’adressage. Le centre de données dispose alors d’une route de retour non ambiguë vers chaque site, et les journaux peuvent distinguer les emplacements. Les routes propres à chaque client sur le serveur OpenVPN, associées aux routes système et aux règles de pare-feu nécessaires, relient ces sous-réseaux aux bons clients.
Cette séparation compte autant en fonctionnement normal que lors d’un basculement. Un enregistreur vidéo ne doit pas obtenir l’accès au distributeur simplement parce que les deux équipements utilisent la même liaison montante.
Protéger les transactions lorsque la liaison de secours est chargée
La transmission vidéo peut se poursuivre lorsque le site passe au cellulaire. Les petits messages du distributeur, sensibles au délai, sont alors en concurrence avec les transferts volumineux sur la liaison montante disponible.
La QoS permet au routeur de donner la priorité à ces messages là où il contrôle la file d’attente. Classez le trafic du distributeur selon son VLAN ou son sous-réseau avant le chiffrement, puis appliquez la priorité appropriée sur le WAN. Une fois le trafic chiffré, les paquets externes ne révèlent plus les mêmes détails applicatifs.
OpenVPN peut recopier le marquage de type de service du paquet interne dans le paquet externe. Cela conserve le marquage pour la suite du trajet, sans déterminer la façon dont l’opérateur le traitera. Effectuez les essais avec le trafic de fond réellement généré sur le site, plutôt qu’avec une connexion par ailleurs inactive.
La taille des paquets mérite également une attention particulière. L’encapsulation VPN ajoute une surcharge, et le chemin cellulaire peut se comporter différemment du chemin filaire. Si les petits échanges fonctionnent mais que les transferts plus importants se bloquent, examinez la MTU du chemin et les paramètres MTU ou TCP MSS adaptés. Un ping réussi n’est qu’un élément de cette vérification.
Préparer les paramètres de reprise avant le déploiement
Une configuration utile est celle qui rétablit correctement la connexion après une panne. Cette courte liste réunit les paramètres du client et du serveur, sans supposer que chaque micrologiciel les expose de la même manière.
Paramètre | Éléments à définir |
|---|---|
Adresse(s) et port du serveur | Un point de terminaison serveur joignable, ainsi qu’un point de secours si le déploiement le nécessite. |
Transport (UDP ou TCP) | Un transport correspondant à l’écoute du serveur et autorisé par le réseau du site. Selon le contexte, TCP sur le port 443 peut être testé comme alternative. |
Certificat de l’AC, certificat client et clé | Une identité distincte pour chaque routeur, une clé privée protégée et un moyen de révoquer son certificat. |
Vérification du certificat serveur | La vérification que le client se connecte au serveur prévu, y compris le rôle attendu du certificat serveur. |
Routes | Les chemins vers les réseaux de traitement requis et les routes de retour vers le sous-réseau du distributeur de chaque site. |
Options keepalive et persist | La détection des pannes, le comportement au redémarrage et la gestion de l’interface lors de la reconnexion. |
MTU / MSS | Des tailles de paquets qui fonctionnent sur les chemins filaire et cellulaire. |
Transmission du marquage ToS | La nécessité éventuelle de reporter le marquage du trafic interne sur les paquets externes du tunnel. |
Sur le serveur, maintenez la cohérence entre l’adresse de tunnel propre à chaque client, le sous-réseau du site, les routes et la politique de pare-feu. Un certificat distinct par routeur permet à l’administrateur de retirer l’accès d’un site sans remplacer les identifiants de tout le parc.
Tester un site avant de reproduire la configuration
Le pilote le plus utile est une version réduite du déploiement : un routeur de référence, les SIM prévues, un accès au serveur et un trafic applicatif représentatif.
Préparer le centre de données. Configurez l’autorité de certification, le certificat serveur, les paramètres propres à chaque client et les règles de pare-feu. Ajoutez un second point de terminaison si l’architecture le prévoit.
Configurer le site de référence. Définissez ses VLAN, ses routes, la QoS et le profil OpenVPN, puis l’ordre de basculement souhaité : WAN filaire, SIM 1 et SIM 2.
Tester chaque scénario de panne. Exécutez une transaction de test autorisée, débranchez la liaison filaire, changez de SIM et répétez le test applicatif après chaque changement. Observez séparément le WAN, le tunnel et l’application, y compris avec une charge de fond.
Reproduire avec des valeurs propres à chaque site. Conservez les paramètres communs, mais attribuez à chaque routeur son propre certificat, sa clé, son sous-réseau de distributeur et son adresse de tunnel.
Identifier et mettre en service les équipements. Vérifiez l’alimentation, Ethernet, le WAN filaire lorsqu’il est utilisé, ainsi que les antennes. Validez la connexion sur le site installé au lieu de vous fier uniquement au résultat obtenu sur banc.
Vous obtenez ainsi une réponse concrète à la question de départ : après la perte d’une liaison, quelle partie revient en premier, laquelle prend plus de temps, et quand le distributeur peut-il de nouveau terminer une transaction ?
Choisir la connexion cellulaire en fonction du site
La technologie cellulaire est un choix à l’intérieur de cette architecture. La couverture et la connexion réellement exploitable sur le lieu d’installation comptent davantage que le choix isolé d’une génération.
Pour cette application, le WR565 de Wavetel fournit une connectivité LTE-A Cat 6, tandis que le WR575 ajoute la 5G. Tous deux prennent en charge OpenVPN, Gigabit Ethernet, deux SIM et le basculement WAN du filaire vers le cellulaire. Vérifiez les interfaces et les options de configuration nécessaires pour le modèle et le micrologiciel utilisés dans le projet.
Choisissez entre les deux selon la couverture des opérateurs sur le site et les exigences du déploiement, puis testez le chemin complet. La même démarche s’applique à la comparaison des routeurs cellulaires industriels : le résultat attendu est le rétablissement de la communication applicative sur la liaison de secours prévue.
Pour examiner votre déploiement, contactez Wavetel en précisant les connexions opérateur envisagées, le réseau du site et le point de terminaison du centre de données.
Questions fréquentes
Le VPN est de nouveau connecté. Pourquoi une transaction peut-elle encore échouer ?
Un tunnel connecté ne confirme qu’une partie du chemin. Vérifiez la route vers l’hôte de traitement, la route de retour, les autorisations du pare-feu et l’état de connexion de l’application. Confirmez la reprise par un test applicatif autorisé plutôt que par le seul statut du VPN.
Faut-il un autre certificat client lors d’un changement d’opérateur ?
Changer de chemin WAN ne nécessite normalement pas de nouveau certificat client. Le certificat identifie le routeur indépendamment de son adresse externe actuelle. Le nouveau chemin doit toujours pouvoir atteindre un serveur qui fait confiance à ce certificat.
Un site peut-il fonctionner uniquement sur le réseau cellulaire ?
Oui, cette architecture peut utiliser le cellulaire comme WAN principal lorsqu’aucune liaison filaire n’est disponible. Testez les opérateurs prévus sur le lieu d’installation et vérifiez la reprise du tunnel et de l’application lors d’un changement de SIM active.
Une seconde SIM fournit-elle un second serveur VPN ?
Non. Elle fournit un autre accès cellulaire. Un point de terminaison VPN de secours est un élément distinct de l’architecture du centre de données et doit être configuré sur le client, par exemple avec des entrées remote supplémentaires.
Références
Manuel OpenVPN 2.6 — remote, keepalive, ping-restart, persist-tun, client-config-dir, iroute, remote-cert-tls et passtos.




