Ogni peer OpenVPN ha bisogno di una riga remote? Non esattamente

Due configurazioni di peer vengono confrontate fianco a fianco, una ha una riga remote e l’altra no, e la conclusione è che una delle due è rotta. Questa inferenza è sbagliata abbastanza spesso da meritare di essere analizzata. La direttiva descrive dove deve essere inviato il primo pacchetto. Non seleziona se il processo agisce come client che inizia o come gateway che attende, e non decide quale lato dimostra la propria identità all’altro.

Che cosa specifica davvero remote

Una voce remote nomina un host, facoltativamente una porta e un trasporto, e facoltativamente diverse di queste voci da provare in ordine.

La sua assenza ha un significato definito e non indefinito: il processo attende e non agisce sui pacchetti di un indirizzo a meno che quel peer non si autentichi. Perciò un gateway che serve utenti in roaming non ha motivo di nominarne alcuno in anticipo.

Leggi la voce come una relazione di indirizzi. Se ci si fida dell’estremità remota lo rispondono i certificati e le opzioni di verifica, non il fatto che sia stato scritto un indirizzo.

Tre disposizioni decidono la risposta

Un client in roaming ha bisogno di una destinazione, perché deve iniziare e senza di essa non sa dove sia il gateway. Un gateway multi-client non ha bisogno di una destinazione per utente, perché i client arrivano e si autenticano. Un collegamento deliberato tra due peer con estremità note può avere una destinazione su un lato, su entrambi o su nessuno, a seconda di quale lato inizi.

Incollare un indirizzo client fisso in un gateway generale è l’errore che deriva dall’ignorare quelle categorie. Funziona per l’unico peer il cui indirizzo è stato registrato e inganna tutti gli altri.

Niente nella direttiva trasforma una configurazione in un server multi-client, e niente nella sua presenza impedisce un ruolo server. Il riferimento di OpenVPN 2.6 documenta separatamente gli argomenti opzionali e il comportamento senza remote, il che è un indizio di quanto siano indipendenti.

I ruoli di trasporto sono un altro asse

Con TCP un lato attende e l’altro stabilisce la connessione. Sono direttive separate dalla destinazione, e mescolarle produce una coppia in cui entrambi attendono o entrambi stabiliscono la connessione.

Esiste anche un ruolo di filtro di origine TCP, ed è per questo che l’affermazione piatta secondo cui un server non può mai contenere remote è sbagliata.

Con UDP non c’è connessione da stabilire, quindi entrambe le estremità usano il trasporto UDP corrispondente e la direttiva dice solo dove puntare. I cambi di indirizzo di un peer autenticato sono gestiti da un comportamento dedicato e non aggiungendo altre voci. Avere il trasporto giusto è un prerequisito perché la destinazione significhi qualcosa, e confondere i due produce configurazioni che sembrano plausibili e non completano mai una stretta di mano.

Perché un remote assente non è una porta aperta

Un processo senza destinazione rifiuta comunque il traffico dei peer che non si autenticano, ed è la parte che le persone trascurano quando leggono la riga assente come un ascoltatore aperto a chiunque.

L’autenticazione e la destinazione sono indipendenti, e la prima è quella che conta per la fiducia.

L’errore inverso è più pericoloso. Un indirizzo di origine fisso può sembrare un controllo di accesso perché è specifico e facile da verificare, ma non prova nulla su chi sia dall’altra parte. Mantieni la verifica dei certificati e i controlli di identità che legano un certificato al suo ruolo. Sostituirli con una corrispondenza di indirizzo scambia un controllo reale con la sua apparenza.

Annota che cosa presuppone la configurazione

Per ogni lato, registra tre cose: come il primo pacchetto raggiunge il peer, quale lato può accettare il trasporto e che cosa verifica ciascun lato dell’altro.

Quelle ipotesi sono il progetto. Le direttive sono solo la loro ortografia.

Se i due file differiscono, verifica se esprimono ipotesi diverse invece di supporre che uno sia sbagliato. Una coppia simmetrica di file non è né necessaria né sufficiente per un tunnel funzionante, e l’asimmetria è spesso la parte che fa funzionare una topologia.