Modellare il traffico OpenVPN: quale interfaccia lo vede?

Fate quattro verifiche: cosa volete limitare, quale pacchetto porta l’informazione che lo identifica, quale interfaccia può vedere il modellatore e cosa sopporta il router mentre cifra. I router vengono forniti sia con una pagina OpenVPN sia con una pagina della larghezza di banda, e la loro convivenza non dimostra nulla su nessuna delle due. L’ordine conta, perché una regola scritta contro il pacchetto sbagliato non corrisponde mai, per quanto sia corretto il suo tasso.

Iniziate dall’obiettivo: limitare un solo dispositivo, condividere la capacità in modo equo o dare priorità a un’applicazione. Ognuno richiede una corrispondenza diversa.

Nominate l’obiettivo prima della regola

Un limite per dispositivo richiede una corrispondenza con l’indirizzo di quel dispositivo, che esiste solo dentro il tunnel. L’equità tra flussi concorrenti richiede una coda che tutti condividono, non una regola per host. La priorità dell’applicazione richiede qualcosa che identifichi l’applicazione, la più difficile delle tre una volta che la cifratura rimuove le intestazioni interne dalla vista. Scrivere prima l’obiettivo vi dice quale fatto vi serve e dove potreste ottenerlo.

Un limite che funziona sul traffico WAN diretto non è prova che lo stesso host sia coperto dentro il tunnel. La regola potrebbe corrispondere a un indirizzo che non compare mai nell’intestazione che il modellatore vede.

Dentro il tunnel o fuori

Con un client VPN di proprietà del router, molti flussi LAN viaggiano dentro un solo trasporto cifrato. Prima dell’incapsulamento il router vede ancora l’origine e la destinazione interne, quindi una politica applicata in quella fase può classificare per dispositivo. Dopo l’incapsulamento l’apparecchiatura ordinaria vede solo la connessione esterna, e una corrispondenza sulla porta VPN non dice nulla su quale dispositivo sia responsabile. Quel singolo fatto decide dove appartiene la regola.

Le piattaforme differiscono nel modo in cui espongono questo aspetto. Alcune forniscono un modellatore che accoda e classifica su un’interfaccia di tunnel; altre trattano i limitatori come regole di interfaccia che si comportano allo stesso modo per il traffico VPN e non VPN; alcune fanno entrambe le cose con capacità diverse. Leggete la documentazione del firmware stesso per l’interfaccia che supporta, invece di copiare un nome di interfaccia dalla guida di un altro produttore.

Identificate dove gli indirizzi restano disponibili, dove avviene la traduzione e quale coda controlla davvero il collo di bottiglia.

Tre politiche, tre tipi di prove

Un limite di velocità si dimostra con un trasferimento sostenuto dal dispositivo limitato mentre un altro trasferisce nello stesso momento. La condivisione equa si dimostra con due flussi che raggiungono tassi simili invece di uno che patisce la fame, il che è una misura diversa. La priorità dell’applicazione si dimostra con un’attività interattiva che resta reattiva durante un trasferimento massiccio, e verificando che il classificatore abbia riconosciuto il flusso. Ogni politica richiede la propria osservazione, e nessuna è dimostrata da una pagina di configurazione.

La classificazione merita un sospetto particolare. Una corrispondenza sulla porta cifrata esterna non può recuperare l’identità di ogni applicazione interna, quindi una regola che sembra dare priorità a un’applicazione può in pratica dare priorità a tutto ciò che esce da quel tunnel. Leggete i contatori della regola invece della sua intenzione.

Misurate il carico cifrato, non quello nudo

Modellazione, classificazione e cifratura competono per un solo processore, e l’accelerazione hardware può far passare il traffico oltre le stesse regole e gli stessi contatori che state osservando. Un valore di throughput da un semplice test di routing dice poco sulla macchina sotto un carico cifrato e modellato. Provate entrambe le direzioni, diversi client rappresentativi e una piccola attività interattiva accanto al trasferimento massiccio. La reattività sotto carico conta più del picco su un collegamento inattivo.

Includete le eccezioni nella misurazione: il traffico che dovrebbe aggirare il tunnel, entrambe le famiglie di indirizzi se entrambe sono in gioco, e cosa succede quando il tunnel è inattivo. Una politica che si comporta in modo sensato solo finché il tunnel è sano è mezza politica.

Scrivete la specifica su tre righe: la corrispondenza del traffico, il punto di applicazione e il carico misurato. OpenVPN più QoS non è una specifica.