Comment configurer le routage par stratégie pour séparer le trafic de sauvegarde et le trafic utilisateur
Séparez le trafic de sauvegarde avec une adresse source explicite ou une marque de paquet, une table de routage dédiée et une règle au périmètre restreint. Ne remplacez pas la route par défaut principale et ne partez pas du principe que les métriques d’interface peuvent distinguer deux charges de travail provenant du même hôte.
Cette conception est utile lorsque les utilisateurs interactifs ont besoin de la liaison montante rapide ou à faible latence, tandis que les sauvegardes planifiées utilisent une passerelle secondaire. Le risque est le routage asymétrique : les réponses sortent par une interface différente de celle de la requête, ce qui peut amener les pare-feu à états ou les pairs distants à rejeter la session. Conservez l’accès à la console, notez les règles d’origine et créez le chemin alternatif avant d’y diriger le trafic.
Choisissez un classificateur qui reste stable
Utilisez une adresse IP source dédiée lorsque le service de sauvegarde peut se lier à une adresse. Elle est plus facile à examiner et résiste mieux aux redémarrages du service que les règles fondées sur des adresses de destination changeantes.
Si les deux charges de travail partagent une adresse, classez les connexions de sauvegarde avec une marque de pare-feu et conservez cette marque pour la connexion. Le routage par politique de Linux évalue les règles avant de consulter la table sélectionnée ; la base de données des politiques de routage constitue donc la couche de décision, tandis que chaque table contient les routes.
Ne classez pas le trafic uniquement selon la plage d’adresses IP d’un fournisseur cloud, sauf si vous contrôlez et maintenez cette liste. Si aucune source, destination, aucun port, utilisateur ou espace de noms stable ne permet d’identifier le flux de sauvegarde, arrêtez-vous et séparez d’abord la charge de travail au niveau du conteneur ou de l’interface réseau.
Créez la table de sauvegarde avant d’ajouter sa règle
Créez une table nommée contenant la route du sous-réseau connecté et la route par défaut de la passerelle de sauvegarde. Sans la route connectée, la passerelle elle-même peut être inaccessible, même si l’entrée par défaut semble correcte.
Interrogez la décision proposée avec une recherche de route fournissant la même adresse source ou la même marque que celle utilisée par le service. Un résultat indiquant l’interface de sauvegarde et la source attendue est concluant ; une recherche qui revient à la table principale signifie que le classificateur ou la priorité est incorrect.
Ajoutez la règle ciblée avec une priorité qui précède la règle générique de la table principale, sans toutefois remplacer les routes locales. Conservez une commande d’annulation explicite dans la même session de terminal et ne testez jamais d’abord via le chemin que vous êtes en train de modifier.
Préservez la symétrie des réponses et l’accès local
Vérifiez que le routeur en amont sait renvoyer le trafic vers le réseau source sélectionné, ou appliquez la traduction d’adresses source uniquement à la limite de sortie appropriée. Une règle de politique peut choisir une route sortante, mais elle ne peut pas faire comprendre à une passerelle distante un sous-réseau privé inconnu.
Vérifiez le filtrage du chemin inverse lorsque des réponses valides arrivent sur une interface que Linux ne sélectionnerait pas avec la table principale. Utilisez un mode adapté à la conception multiconnectée plutôt que de désactiver la validation globalement, puis vérifiez ce choix avec des captures de paquets sur les deux interfaces.
Conservez le trafic de gestion, DNS et LAN dans la table principale, sauf si la séparation l’exige. Le guide ZimaSpace sur l’utilisation fiable d’un partage réseau constitue un complément utile lorsque la sauvegarde routée dépend également d’un chemin de stockage monté.
Testez aussi bien l’échec que la réussite
Lancez un transfert interactif et une sauvegarde, puis examinez les compteurs d’interface et l’état des connexions. Les octets de sauvegarde doivent augmenter uniquement sur la sortie de sauvegarde, tandis que la session utilisateur reste sur le chemin principal.
Bloquez ou déconnectez temporairement la passerelle de sauvegarde pendant une période contrôlée. Si la conception est à défaillance bloquante, la sauvegarde doit s’arrêter sans basculer silencieusement vers la liaison utilisateur ; si un basculement est prévu, documentez ce comportement et plafonnez sa bande passante.
Redémarrez une fois, puis répétez la charge de travail simultanée initiale afin de vérifier la persistance de l’ordre des règles et des marques. Arrêtez-vous lorsque les recherches, les captures de paquets et les journaux de l’application concordent ; revenez en arrière si l’accès de gestion change, si les réponses deviennent asymétriques ou si du trafic sans rapport entre dans la table de sauvegarde.
Produits recommandés
Assistance et conseils
Plus à lire
Guide de stockage pour l’enregistrement de la télévision en direct : capacité, conservation et nettoyage
Mesurez les enregistrements réels, prévoyez une marge de sécurité, combinez les limites d’ancienneté et de capacité, et vérifiez que le programme admissible le plus...
Flux de récupération des métadonnées multimédias à domicile après la restauration d’une base de données
Protégez l’état restauré, vérifiez l’identité et les chemins des médias, puis corrigez les illustrations ou les correspondances manquantes dans une bibliothèque pilote avant d’appliquer...
Liste de contrôle de compatibilité du client Jellyfin pour l’audio, la vidéo et les sous-titres
Testez des fichiers représentatifs en ne faisant varier qu’un paramètre à la fois, puis consignez pour chaque client la lecture directe, le remuxage, la...
