Panoramica #
Questo articolo spiega come identificare e risolvere problemi di routing asimmetrico in un RELIANOID distribuzione quando il bilanciatore del carico ha più interfacce di rete connesse a diverse subnet.
Questa situazione può verificarsi quando i client frontend devono accedere ai servizi backend situati in un'altra subnet mentre il bilanciatore del carico ha interfacce in entrambe le reti.
Un comportamento di routing non corretto può causare l'uscita del traffico di risposta attraverso un'interfaccia diversa da quella utilizzata per la richiesta in entrata, con conseguente routing asimmetrico.
Descrizione del problema #
In alcune distribuzioni, il RELIANOID il bilanciatore del carico è configurato con più interfacce connesse a reti diverse.
La seguente configurazione rappresenta un ambiente di esempio utilizzato a scopo dimostrativo.
| Interfaccia | Reti | Missione |
| eth0 | 192.168.1.0/24 | Management |
| eth1 | 192.168.110.0/24 | Frontend |
| eth2 | 192.168.100.0/24 | Applicazione / Backend |
I server backend si trovano nella sottorete 192.168.100.0/24 e vi si accede tramite farm configurate sul bilanciatore di carico.
Tuttavia, alcuni client situati nella rete 192.168.110.0/24 necessitano anche di accedere ai servizi ospitati nella rete 192.168.100.0/24.
Poiché il bilanciatore di carico ha un'interfaccia in entrambe le reti e l'inoltro IP è attivo per impostazione predefinita, il sistema potrebbe instradare il traffico di risposta direttamente attraverso l' interfaccia frontend (eth1) anziché attraverso il gateway previsto.
Ciò si traduce in un instradamento asimmetrico , che può causare errori di connessione o perdita di pacchetti.
Esempio di configurazione dell'interfaccia #
Che cosa è il routing asimmetrico #
Il routing asimmetrico si verifica quando il traffico in entrata e in uscita della stessa connessione seguono percorsi di rete diversi.
Esempio di flusso #
Percorso di destinazione: 192.168.110.11 tramite eth2 (Client) > 192.168.100.100 (Bilanciatore di carico) > 192.168.100.42 (Backend)
Percorso di ritorno (errato): 192.168.100.42 (Backend) > 192.168.100.100 (Load Balancer) > 192.168.110.11 tramite eth1 (Client)
Poiché il traffico di ritorno passa attraverso un'interfaccia diversa, i dispositivi intermedi come firewall o router potrebbero ignorare i pacchetti.
Come funzionano le tabelle di routing #
RELIANOID usa tabelle di routing per interfaccia per controllare come il traffico viene inoltrato tra le reti.
Ogni interfaccia genera automaticamente la propria tabella di routing.
Esempi di tabelle di routing: table_eth1, table_eth2
Queste tabelle di routing definiscono:
- Percorsi associati all'interfaccia
- Gateway utilizzati per l'inoltro del traffico
- Interfacce autorizzate a instradare il traffico
All'interno di ogni tabella di routing, le interfacce possono essere configurate come:
Interfacce gestite #
Interfacce autorizzate a instradare il traffico all'interno della tabella di routing utilizzando la funzionalità di inoltro IP.
Interfacce non gestite #
Le interfacce escluse dalle decisioni di routing per quella tabella e l'inoltro IP non verranno applicate a tali interfacce.
Controllando quali interfacce sono gestite e quali non gestite, gli amministratori possono influenzare il modo in cui il traffico scorre attraverso il bilanciatore del carico e prevenire conflitti di routing.
Esempio di tabella di routing #
Soluzione #
Per risolvere il problema del routing asimmetrico, l'interfaccia in conflitto deve essere esclusa dalla tabella di routing associata alla rete backend.
In questo scenario, eth1 dovrebbe essere rimosso dalla tabella di routing table_eth2, assicurando che il traffico venga instradato attraverso il gateway corretto.
Soluzione tramite l'interfaccia utente Web #
- Vai a: Rete > Routing
- Selezionare la tabella di routing associata all'interfaccia backend:
table_eth2 - Scorri fino in fondo alla pagina.
- individuare il Interfacce gestite .
- Spostare l'interfaccia eth1 da Interfacce gestite a Interfacce non gestite.
Ciò impedisce che il traffico venga instradato direttamente attraverso l'interfaccia frontend quando viene utilizzata la tabella di routing backend.
Soluzione tramite CLI #
La stessa configurazione può essere applicata anche utilizzando RELIANOID CLI.
Passaggio 1: abilitare l'accesso API #
Vai a: Sistema > Impostazioni utente
Abilita l'accesso API e configura una chiave API. Puoi definire la tua chiave o generarne una casuale.
Dopo aver creato la chiave, copiala e salvala, poiché sarà richiesta la prima volta che accedi alla CLI utilizzando noid-cli
Passo 2: accesso RELIANOID CLI #
Dalla console di sistema, eseguire:
noid-cli
Inserisci la chiave API quando richiesto.
Passaggio 3: rimuovere l'interfaccia dalla tabella di routing #
Esegui il seguente comando:
tabella di routing di rete non gestita aggiungi tabella_eth2 -interfaccia eth1
Questo comando impedisce che il traffico venga instradato attraverso eth1 quando si utilizza la tabella di routing table_eth2.
Passaggio 4: Ripristina la configurazione (facoltativo) #
Se necessario, la configurazione può essere ripristinata con il seguente comando:
tabella di routing di rete non gestita rimuovi table_eth2 eth1
Best Practices #
- Eseguire modifiche di routing durante orari di basso traffico o finestre di manutenzione.
- Convalidare la connettività dopo aver applicato la configurazione.
- Assicurarsi che altri servizi non siano interessati dalle modifiche al routing.
Conclusione #
Possono verificarsi problemi di routing asimmetrico quando un bilanciatore del carico è connesso a più reti e il traffico ritorna attraverso un'interfaccia diversa da quella utilizzata per la connessione in entrata.
In RELIANOID, questo problema può essere risolto modificando le configurazioni della tabella di routing ed escludendo le interfacce in conflitto da tabelle di routing specifiche.
Ciò garantisce che il traffico segua il percorso di rete corretto e previene problemi di connettività.
