VPN su più percorsi: quattro garanzie che l’operatore deve fornire

Aggiungete un secondo collegamento WAN e i tunnel si attivano, ma una copia di file si blocca ancora quando un percorso vacilla. I collegamenti sono sani e i processi VPN sono in esecuzione; ciò che manca è un contratto tra l’operatore e il tunnel. Diversi socket non si comportano automaticamente come un’unica connessione, e l’applicazione sopra non nota la differenza finché la consegna non si rompe. Ogni parte del contratto corrisponde a un guasto che potete testare, ed è questo che lo rende utile.

Scrivete quel contratto prima di scegliere un prodotto. Ha quattro parti: il flusso che riceve la VPN, come l’operatore recupera i dati mancanti, quale identità dell’endpoint sopravvive a un cambio di percorso e come si comporta l’insieme quando un percorso fallisce.

Il sintomo: i collegamenti sono attivi, la sessione cade lo stesso

Un grafico di monitoraggio che mostra entrambi i collegamenti attivi dimostra solo che ogni percorso può trasportare traffico. Non dimostra che la VPN veda un unico flusso ordinato, che un pacchetto perso su un percorso venga recuperato su un altro, né che il peer sappia ancora con quale sessione sta parlando. Il resto del contratto copre ciò che quel grafico non può mostrare.

Quando un trasferimento si blocca, accertate se l’operatore ha continuato a consegnare sul percorso sopravvissuto. Se la sessione muore mentre il secondo collegamento è inattivo, l’operatore non l’ha mai usato. Se la sessione sopravvive ma i dati arrivano fuori ordine o duplicati, l’operatore sposta pacchetti senza un contratto a livello di connessione. I timestamp su entrambi i lati di solito lo chiariscono.

Questa distinzione decide la correzione. Un problema di routing o di policy richiede un cambio di selezione del percorso; uno strato mancante di ordinamento e ripristino richiede un trasporto diverso, non un buffer più grande.

Garanzia uno: un flusso di byte a livello di connessione

Se la VPN ha bisogno di un flusso ordinato e affidabile, l’operatore deve identificare intervalli di byte sopra il singolo percorso. Ogni connessione TCP sottostante numera solo i propri segmenti, quindi un ricevente non può riordinare tra percorsi usando solo quei numeri.

Multipath TCP è l’esempio standardizzato. Presenta un flusso di byte affidabile coordinando diversi sottoflussi TCP, con mappatura delle sequenze e conferma a livello di dati. L’applicazione legge un flusso, non il sottoflusso che ha consegnato un pezzo per primo.

Su Linux, MPTCP è opt-in per socket tramite IPPROTO_MPTCP. Quando la negoziazione non può usare il comportamento multipath, il fallback documentato è TCP ordinario, il che significa che l’applicazione può continuare su un percorso senza usare mai il secondo. Verificate quale comportamento ha effettivamente negoziato il socket distribuito invece di presumere che l’impostazione del kernel sia stata applicata.

Garanzia due: ordinamento, duplicazione e ripristino

Percorsi con ritardi e tassi di perdita diversi costringono l’operatore a bufferizzare, riordinare e ritrasmettere. Il contratto deve indicare quanta bufferizzazione è consentita, quale contropressione vede l’applicazione e quale percorso trasporta una ritrasmissione.

Un percorso che resta connesso ma smette di consegnare è più difficile di una chiusura pulita. L’operatore deve rilevarlo, spostare i dati in sospeso ed evitare di attendere per sempre un segmento che non arriverà mai. Un semplice controllo che entrambi i collegamenti siano attivi non copre questo stato.

La duplicazione richiede una regola propria. Inviare lo stesso carico su entrambi i percorsi può migliorare la latenza, ma il ricevente deve sopprimere la copia prima che raggiunga la VPN. L’anti-replay IPsec è opzionale per associazione di sicurezza e controlla i numeri di sequenza; uno strato di duplicazione che riordina o ripete pacchetti può attivarlo o nascondere il problema finché il tunnel cade.

Garanzia tre: identità dell’endpoint e unione dei percorsi

Il peer ha bisogno di un modo stabile per riconoscere la sessione quando appare un nuovo percorso. Se ogni percorso viene autenticato come tunnel separato, la VPN può vedere due sessioni invece di una. Se l’operatore unisce i percorsi sotto una sessione, deve definire come viene autenticato il nuovo percorso e cosa succede al vecchio.

Annotate quali indirizzi e identificatori restano stabili: l’endpoint del tunnel, l’identificatore di sessione dell’operatore e qualsiasi proxy intermedio. Un proxy aggiunge un’altra frontiera di disponibilità e fiducia anche quando non vede mai il carico protetto.

Qui risiede anche la policy. Un percorso che si unisce da una rete inattesa può essere tecnicamente valido e violare comunque il modello di fiducia previsto. Decidete se i nuovi percorsi sono accettati automaticamente, richiedono autenticazione o vengono rifiutati.

Garanzia quattro: comportamento limitato in caso di guasto

Testate un guasto completo del percorso, non solo un percorso lento. Il percorso sopravvissuto dovrebbe trasportare la sessione senza una crescita illimitata della memoria, e il ripristino non dovrebbe dipendere da un timer più lungo di quanto l’applicazione possa tollerare. Quando il percorso guasto ritorna, l’operatore deve decidere se ribilanciare o lasciare il flusso dov’è.

Impostate limiti per bufferizzazione, ritrasmissione e numero di percorsi, poi verificateli in caso di perdita, riordino, duplicazione e squilibrio di ritardo. La larghezza di banda aggregata è il numero meno interessante qui; la continuità di consegna e i limiti di memoria sono il contratto.

Tenete lo stato di ripristino dell’operatore separato dallo stato crittografico della VPN. Uno strato di affidabilità personalizzato che sostituisce autenticazione o crittografia consolidate non è una scorciatoia, e riutilizzare numeri di sequenza tra strati rende inaffidabili la protezione anti-replay e la diagnostica.

Accettate l’operatore con un piano di test

Scrivete le quattro garanzie come controlli superato o fallito: un flusso ordinato, ripristino definito, identità di sessione stabile, comportamento di guasto limitato. Eseguite ogni controllo con un percorso degradato e poi con un percorso rimosso.

Un singolo trasferimento di file riuscito attraverso un cambio di percorso non dimostra un funzionamento continuo. Ripetete il trasferimento alternando il percorso preferito e ispezionate sia la vista dell’operatore sia i contatori della VPN. Se i due non concordano su quale percorso ha trasportato i dati, il contratto non è ancora osservabile.

Conservate la matrice approvata con il deployment. Indica al prossimo ingegnere quale comportamento è stato promesso, quali combinazioni di percorsi sono state testate e quale modalità di guasto resta non supportata, senza un altro giro di ipotesi dalle spie di stato dei collegamenti.