Rotta dell’appliance OpenVPN: proprietario della configurazione o script di avvio?

Aggiungete una rotta di filiale, funziona, e poi un aggiornamento del firmware o un salvataggio dall’interfaccia web la rimuove. Due correzioni sembrano ugualmente ragionevoli in quel momento: mettere la rotta nella fonte di configurazione supportata dell’appliance, o aggiungerla al file generato da uno script di avvio. Si comportano allo stesso modo per una settimana e divergono al secondo aggiornamento. Questo articolo confronta ciò che ciascuna possiede realmente.

I due candidati possiedono cose diverse

La fonte di configurazione supportata è tutto ciò che l’appliance tratta come input: un campo della GUI, un profilo importato, una directory documentata per client, un database di impostazioni che il pacchetto di gestione legge. Il server.conf generato è output. Modificare l’output funziona finché il generatore non viene rieseguito, e questo accade al salvataggio, al riavvio e all’aggiornamento.

L’approccio con script applica patch a quell’output dopo che il generatore ha finito. È una tecnica legittima per un laboratorio, ed è l’impostazione predefinita sbagliata per una filiale, perché rende la rotta dipendente dalla corrispondenza di testo invece che da un campo documentato.

Cosa rigenera l’appliance, e quando

I pacchetti di gestione di solito tengono le impostazioni in un database o in un insieme di modelli e generano la configurazione del demone all’avvio. Un salvataggio dall’interfaccia web spesso riscrive l’intero file invece di applicare una patch a una riga. Se la vostra modifica viveva in quel file, ora è sparita, e nulla registra un avviso, perché dal punto di vista dell’appliance non è andato perso nulla.

I wrapper di avvio hanno un secondo modo di guasto. Un grep su una direttiva con una certa spaziatura smette di corrispondere dopo un cambio di modello, e lo script non fa nulla in silenzio. Peggio ancora, un aggiornamento del firmware può sostituire il wrapper con una nuova versione, portandosi via la patch. Avete allora una rotta che è esistita per un anno ed è sparita durante una manutenzione che nessuno ha collegato al routing.

Cosa deve esprimere il proprietario supportato

Un prefisso di filiale richiede tre affermazioni, non una. Il client deve apprendere la rotta, il server deve sapere quale client autenticato possiede il prefisso, e il lato filiale deve restituire il traffico all’indirizzo del tunnel che gli è stato assegnato. In termini OpenVPN ciò significa un route inviato, un iroute corrispondente legato al client, e un percorso di ritorno dall’altro lato.

È qui che le interfacce delle appliance traggono in inganno. Una casella etichettata «consenti ai client di accedere alla LAN del server» descrive il traffico verso la rete propria del server. La vostra filiale è la direzione opposta: una rete dietro un client, raggiungibile dal lato server. La stessa etichetta non implica supporto per questo, e una direttiva valida in un file non è una promessa che il pacchetto la preservi.

Quando non esiste alcun controllo supportato

A volte la versione installata davvero non può esprimere una rotta specifica di un peer. Allora le opzioni oneste sono un altro gateway che controllate, o una modalità sito a sito supportata a entrambe le estremità. Entrambe le estremità devono parlarla. Una pagina prodotto che dice sito a sito non rende un profilo OpenVPN arbitrario intercambiabile con il tunnel di un altro protocollo, e forzare quell’abbinamento di solito produce un tunnel mezzo connesso che sembra a posto in una pagina di stato.

Scegliete l’opzione che potete descrivere in una frase a chi erediterà la rete. Se la risposta richiede di menzionare un percorso di script e un modello di testo, il progetto è già fragile.

Rendete l’intento verificabile

Registrate il contratto fuori dall’appliance: identità effettiva del client, prefisso, gateway di ritorno e il campo supportato che fornisce ciascuno. Esportate la configurazione tramite il meccanismo supportato affinché una ricostruzione abbia un riferimento, e verificate il servizio dopo una riconnessione, un riavvio e un aggiornamento anziché solo dopo la modifica.

Confrontate il risultato generato con quel registro quando qualcosa si rompe, invece di ripristinare una riga inspiegata e sperare.riferimento di OpenVPN 2.6 è il posto per confermare come interagiscono route e iroute prima di discutere con un’interfaccia.

Lista di controllo per la prossima modifica: nominate il proprietario, dichiarate il contratto in tre parti, esportate l’intento e riprovate dopo gli eventi del ciclo di vita dell’appliance, non dopo la vostra modifica.