Une deuxième connexion Internet n’est un secours utile que si les processus de travail importants fonctionnent réellement par ce chemin. OPNsense peut gérer plusieurs accès WAN. La réussite du basculement dépend aussi du DNS, des adresses, des sessions et des exigences des applications.
Définir d’abord le comportement attendu
Le basculement utilise un chemin de secours lorsque l’accès privilégié tombe en panne ou offre une qualité insuffisante. La répartition de charge distribue les connexions selon une logique définie. Aucun des deux mécanismes n’additionne automatiquement la bande passante pour chaque téléchargement. Avant la configuration, il faut définir quel accès chaque application doit utiliser.
Les contrats comptent également : le secours comporte-t-il un quota de données ? La connexion mobile passe-t-elle par une traduction d’adresses supplémentaire ? Quelle adresse publique les systèmes distants ou les listes d’autorisation utilisent-ils ? Une session Internet ordinaire qui fonctionne ne prouve pas que les services entrants et les tunnels intersites peuvent emprunter le même secours.
Le test de passerelle doit détecter la panne pertinente
La documentation OPNsense présente les passerelles surveillées et les groupes de passerelles comme des éléments de base. Le seul état du lien physique ne détecte pas toutes les pannes en amont. La cible de surveillance doit être accessible par le chemin prévu et indiquer de manière pertinente si celui-ci reste utilisable.
Les seuils et les cibles de test sont choisis avec soin puis observés. Un hôte distant difficilement accessible ne doit pas provoquer des changements de ligne incessants. Inversement, un routeur opérateur qui répond encore localement ne doit pas faire paraître sain indéfiniment un accès Internet interrompu. La surveillance fait partie du modèle d’exploitation.
Le DNS et les états de connexion font partie du secours
Les groupes de passerelles et les règles de routage adaptées concernent le trafic des postes ; le trafic produit par le pare-feu lui-même et sa résolution de noms doivent aussi convenir. Le DNS est donc testé en situation de panne. Un site déjà visité peut se charger depuis le cache alors que les nouvelles résolutions de noms échouent.
Les sessions actives peuvent être interrompues lorsque l’adresse publique change. La documentation OPNsense aborde notamment la gestion des états et les connexions persistantes, ou sticky connections. Ces réglages ne s’activent pas systématiquement : une application peut nécessiter un chemin de sortie stable, tandis qu’une autre doit se reconnecter après la panne.
Quatre tests rendent le bénéfice visible
Le plan de recette couvre une panne réelle de l’accès principal, une panne en amont du routeur opérateur encore connecté, les sessions applicatives nouvelles et déjà actives, puis le retour à l’accès principal. Un test planifié se déroule dans un créneau adapté, avec un chemin d’administration accessible.
On observe par exemple la téléphonie, le VPN, l’application métier, le DNS et un éventuel quota de données mobiles. Les interruptions mesurées sont documentées, sans promettre un fonctionnement ininterrompu. DAXS associe choix des accès, routage et tests applicatifs pour définir un secours dont le comportement est connu dans l’entreprise.
Communication et opérateurs · Planifier l’infrastructure · Parlons de l’accès de secours
Sources : OPNsense : Multi-WAN, basculement et répartition (lien externe) · OPNsense : passerelles et surveillance (lien externe)
