Più remote OpenVPN: elenco di failover, non aggregazione di collegamenti

Due righe remote in un profilo sembrano una seconda corsia; sono un secondo tentativo. Quando il primo endpoint smette di rispondere, il client passa oltre e la sessione non diventa più larga. Chiamate la lista failover subito, o regolerete la manopola sbagliata.

Che cosa vi dà un elenco di remote

Trattate il profilo come un insieme ordinato di tentativi, non come una riserva di capacità. Ogni voce ha il suo turno per alzare il tunnel, e la sessione vive su quella che ha risposto. Un elenco più lungo migliora le probabilità di connessione, non la dimensione del tubo.

La vera aggregazione è un’altra macchina. Dividere un flusso su più percorsi richiede software a entrambe le estremità per distribuire e riassemblare il traffico in ordine.

Un fornitore che promette tunnel più veloci da più server vende quel secondo modello, non un elenco più lungo. Se il client prova gli endpoint solo a turno, cinque voci cambiano le probabilità e nient’altro. Osservate un’interruzione: la sessione cade e torna altrove, cosa che il registro mostra come nuovo endpoint, mai come tubo più largo.

Blocchi che tengono le impostazioni con un solo endpoint

Una riga remote semplice porta un indirizzo, e talvolta una porta e un protocollo. Quando un endpoint ha bisogno di un proxy, o di un trasporto che il resto del file non usa, mettete quelle impostazioni in un blocco di connessione che le tenga con lui. I blocchi in linea funzionano anche in un unico file .ovpn, ed è così che viene distribuita la maggior parte dei profili.

Tutto ciò che è fuori da un blocco funge da valore predefinito per le voci che non lo sovrascrivono. Ecco perché un blocco costruito e quattro remote semplici si comportano in modi che l’elenco degli indirizzi non può spiegare.

Eliminare un blocco che non riconoscete non è cosmesi. L’endpoint a cui apparteneva torna ai valori predefiniti del file, che possono essere un trasporto diverso da quello su cui ascolta. Togliete l’involucro sbagliato e una voce fallisce mentre le altre funzionano, così sembra un server guasto e non un profilo rotto. Leggete ogni remote con il suo trasporto, porta e proxy prima di modificare.

Ordine dei tentativi e costo di remote-random

L’ordine conta perché ogni voce morta costa tempo prima del tentativo successivo. Mettete per primo l’endpoint che volete e trattate il resto come ripieghi classificati.

remote-random mescola l’ordine iniziale, cosa che distribuisce il carico tra server equivalenti e si ritorce contro quando un endpoint è chiaramente primario. In ogni caso, registrate l’endpoint scelto dal client; il nome del profilo non dice nulla quando una connessione sembra lenta. Un grep della riga di collegamento in un registro dettagliato mostra dove è atterrata la sessione.

Mescolare gli operatori rompe la dichiarazione di fiducia

Un profilo è anche un’affermazione sull’identità: questi indirizzi sono il servizio che volevate raggiungere, e il certificato appuntato appartiene a esso. Gettare server pubblici gratuiti in quel file rompe l’affermazione: i loro certificati e il vostro descrivono servizi diversi. Il risultato abituale è un errore di identità, o credenziali offerte a un host fuori dalla rete del vostro provider. Tenete le alternative dentro l’insieme che il vostro operatore distribuisce, con credenziali e materiale di fiducia corrispondenti.

Se vi servono endpoint da due provider, è routing, non una modifica del profilo. Risolvetelo sopra il tunnel, dove potete dire quale traffico prende quale percorso.

Provate ogni voce invece di supporre

Dopo un aggiornamento del profilo approvato, collegatevi di proposito a ogni endpoint richiesto e confermate quale trasporto è salito. Un’esecuzione dettagliata lo rende visibile. Avviate openvpn --config office.ovpn --verb 4 e leggete la riga di collegamento per l’indirizzo che vi aspettavate. Poi controllate le risorse dietro il tunnel; una voce può completare la stretta di mano e comunque non instradarvi da nessuna parte.

Il failover ha bisogno di un proprio test invece che di una speranza. Bloccate il primo endpoint in laboratorio, avviate il client e misurate quanto tempo impiega a passare oltre. Un elenco lungo dietro una prima voce lenta è peggio di uno corto che parte bene.

Ricontrollate l’elenco ogni volta che l’operatore lo cambia. Un insieme importato è utile solo finché le sue voci esistono e parlano il trasporto che i vostri blocchi descrivono. Il manuale di OpenVPN 2.6 copre qui le direttive remote, connection e random-order, ed è la versione da controllare quando la sintassi è dubbia.