Come configurare il policy routing per separare il traffico dei backup da quello degli utenti

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

How to Set Up Policy Routing for Separate Backup and User Traffic - Zima Store Online

Separa il traffico dei backup con un indirizzo sorgente esplicito o un contrassegno di pacchetto, una tabella di routing dedicata e una regola con ambito ristretto. Non sostituire la route predefinita principale e non presumere che le metriche delle interfacce possano classificare due carichi di lavoro dallo stesso host.

Questo design è utile quando gli utenti interattivi hanno bisogno dell'uplink veloce o a bassa latenza, mentre i backup pianificati utilizzano un gateway secondario. Il rischio è il routing asimmetrico: le risposte escono da un'interfaccia diversa da quella della richiesta, inducendo i firewall stateful o i peer remoti a rifiutare la sessione. Mantieni l'accesso alla console, registra le regole originali e crea il percorso alternativo prima di indirizzarvi il traffico.

Scegli un classificatore stabile

Usa un IP sorgente dedicato quando il servizio di backup può associarsi a un indirizzo. È più facile da esaminare e resiste meglio ai riavvii del servizio rispetto alle regole basate su indirizzi di destinazione variabili.

Se entrambi i carichi di lavoro condividono un indirizzo, classifica le connessioni di backup con un contrassegno firewall e conserva tale contrassegno per la connessione. Il routing basato su policy di Linux valuta le regole prima di consultare la tabella selezionata; il database delle policy di routing è quindi il livello decisionale, mentre ogni tabella contiene le route.

Non classificare il traffico esclusivamente in base all'intervallo IP di un provider cloud, a meno che tu non ne controlli e aggiorni l'elenco. Se nessun elemento stabile - sorgente, destinazione, porta, utente o namespace - identifica il flusso di backup, fermati e separa prima il carico di lavoro a livello di container o interfaccia di rete.

Crea la tabella dei backup prima di aggiungere la relativa regola

Crea una tabella denominata contenente la route della subnet connessa e la route predefinita del gateway dei backup. Senza la route connessa, il gateway stesso potrebbe essere irraggiungibile anche se la voce predefinita sembra corretta.

Interroga la decisione proposta con una ricerca della route che fornisca lo stesso indirizzo sorgente o contrassegno che utilizzerà il servizio. Un risultato che mostra l'interfaccia dei backup e la sorgente prevista è positivo; se la ricerca ricade nella tabella principale, il classificatore o la priorità sono errati.

Aggiungi la regola circoscritta a una priorità che preceda la regola generica della tabella principale, ma che non sovrascriva le route locali. Mantieni nella stessa sessione del terminale un comando di rollback esplicito e non eseguire mai il primo test attraverso il percorso che stai modificando.

Mantieni la simmetria delle risposte e l'accesso locale

Verifica che il router upstream sappia restituire il traffico alla rete sorgente selezionata, oppure applica il NAT sorgente solo al corretto confine di uscita. Una regola di policy può scegliere una route in uscita, ma non può fare in modo che un gateway remoto comprenda una subnet privata sconosciuta.

Controlla il filtraggio del percorso inverso quando risposte valide arrivano su un'interfaccia che Linux non selezionerebbe usando la tabella principale. Usa una modalità adatta alla configurazione multi-homed anziché disabilitare globalmente la convalida e verifica la scelta acquisendo pacchetti su entrambe le interfacce.

Mantieni il traffico di gestione, DNS e LAN nella tabella principale, salvo che la separazione non sia necessaria. La guida ZimaSpace sull'uso affidabile delle condivisioni di rete è un utile complemento quando il backup instradato dipende anche da un percorso di archiviazione montato.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

Testa sia i guasti sia il funzionamento corretto

Avvia un trasferimento interattivo e un backup, quindi esamina i contatori delle interfacce e lo stato delle connessioni. I byte del backup dovrebbero aumentare solo sull'uscita dedicata ai backup, mentre la sessione dell'utente dovrebbe rimanere sul percorso principale.

Blocca o disconnetti temporaneamente il gateway dei backup durante una finestra controllata. Se il design è fail-closed, il backup dovrebbe arrestarsi senza migrare silenziosamente al collegamento dell'utente; se è previsto il failover, documenta questo comportamento e limita la larghezza di banda.

Riavvia una volta e ripeti il carico di lavoro simultaneo originale, così da dimostrare che l'ordine delle regole e i contrassegni persistono. Fermati quando ricerche, acquisizioni di pacchetti e log dell'applicazione concordano; esegui il rollback se cambia l'accesso alla gestione, le risposte diventano asimmetriche o traffico non correlato entra nella tabella dei backup.