Due uplink ma un solo tunnel: failover, bilanciamento o aggregazione

Due linee internet possono rendere una VPN più disponibile, e possono renderla più veloce per alcuni carichi di lavoro, ma il meccanismo decide quale delle due cose accade. Un router con due rotte predefinite non è aggregato, e un tunnel che trasporta migliaia di connessioni interne resta un solo flusso esterno. Nominare la promessa per prima è la differenza tra un progetto e una delusione costosa. La tabella qui sotto separa le opzioni in base a ciò che ciascuna richiede all’estremità remota e a ciò che una perdita di collegamento fa a un trasferimento.

Tre promesse, e solo una ha bisogno di un partner

Il failover mantiene un percorso disponibile quando il collegamento preferito scompare. Il bilanciamento per hash dei flussi distribuisce flussi indipendenti su entrambi gli uplink. L’aggregazione di un singolo flusso permette a un trasferimento di usare entrambi i collegamenti insieme. Sono prodotti diversi con requisiti diversi, e solo l’ultimo ha bisogno della cooperazione di qualcosa oltre il vostro router.

Niente in quella tabella è un motivo per comprare una seconda linea. Quello che fa è impedire che un progetto di failover venga valutato come se fosse aggregazione.

Perché un tunnel sembra un solo flusso per il router

Un router che bilancia il carico applica un hash agli indirizzi di origine e destinazione insieme alle porte, poi invia l’intero flusso dove punta l’hash. Un tunnel VPN è uno di questi flussi dal punto di vista del router, qualunque cosa giri al suo interno. Le connessioni interne non arrivano mai alla decisione dell’hash, perché l’intestazione esterna ha già deciso il percorso. Per questo un secondo uplink può raddoppiare la capacità totale per molti utenti e non cambiare nulla nel grande trasferimento di un solo utente.

Due tunnel separati possono darvi due candidati, ma hanno ancora bisogno di una politica deliberata che assegni il traffico e mantenga le risposte sul percorso che ha portato la richiesta. L’instradamento asimmetrico è il risultato abituale di saltare quel passaggio. Il minimo è una politica che nomini il flusso, il collegamento preferito e il collegamento di riserva.

L’aggregazione Ethernet non attraversa provider non correlati, perché l’estremità remota deve partecipare al protocollo di aggregazione. Un’aggregazione tra due provider internet è un progetto di ricerca a meno che esista un endpoint cooperativo.

Cosa richiede il TCP multipath a entrambe le estremità

La documentazione di Linux su Multipath TCP descrive diversi sottoflussi appartenenti a una connessione. Il supporto del kernel a un’estremità non cambia nulla da solo, dato che anche il peer deve accettare quei sottoflussi. Un proxy sul lato remoto è l’altra disposizione comune, e diventa un componente con la propria capacità e disponibilità da pianificare. La stessa logica esclude una risposta facile per WireGuard, il cui trasporto è UDP: MPTCP fa crescere sottoflussi TCP e non può aggregare quel tunnel senza qualcos’altro nel progetto.

Verificate se la funzione del kernel è attiva prima di progettare intorno a essa, perché molte distribuzioni la forniscono disattivata. Questi tre comandi rispondono in un minuto.

sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits show

Scegliete dal carico di lavoro, non dalla brochure

Se il carico di lavoro è composto da molte sessioni indipendenti, il bilanciamento per hash dei flussi può aggiungere capacità senza cooperazione all’estremità remota. Se è un solo grande trasferimento, solo un progetto di aggregazione aiuterà, e quel progetto ha bisogno di un peer cooperativo. Se il requisito è che il lavoro continui quando un collegamento muore, la risposta è il failover e la velocità di un singolo trasferimento è irrilevante.

Scrivete il requisito in una frase con un verbo dentro: un backup termina il doppio più in fretta, oppure un collegamento caduto non termina una sessione. Gli obiettivi vaghi producono progetti che nessuno può accettare o rifiutare. Poi decidete cosa può essere l’estremità remota, perché l’opzione più economica è spesso quella che non richiede nulla di nuovo lì. Quel vincolo elimina la maggior parte delle affermazioni della brochure prima della prima riunione.

Tenete le tre promesse separate nel documento dei requisiti. Un progetto che rivendica tutte e tre di solito ne consegna una e presume in silenzio le altre. La sezione successiva verifica quale viene realmente consegnata.

Provate un trasferimento e molti, poi staccate un collegamento

Confrontate un trasferimento sostenuto con diversi trasferimenti paralleli verso la stessa destinazione, e registrate perdita, ritardo e utilizzo per collegamento di ciascuno. Un guadagno solo con sessioni parallele indica la distribuzione dei flussi, non l’aggregazione di un singolo flusso. Provate separatamente la perdita di un uplink, perché la capacità mentre entrambi i collegamenti funzionano non dice nulla sul failover per una sessione stabilita. Registrate la rotta, il socket e i contatori di ritrasmissione prima e dopo ogni prova.

ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5

Quando il trasferimento singolo usa ancora un solo uplink, il progetto fa esattamente ciò che implica un hash di flusso. Quando i trasferimenti paralleli si distribuiscono su entrambi, il bilanciamento funziona e l’aggregazione no. Registrate quale delle tre promesse il progetto mantiene davvero, e la prossima conversazione sulla capacità partirà da prove invece che da un’affermazione del fornitore.