Servire OpenVPN su TCP e UDP da un solo host
Un processo associa un solo trasporto prima della 2.7. Confronta una coppia TAP in bridge, due sottoreti TUN e un pool condiviso, poi abbina ogni profilo al suo listener.
Le reti che consentono solo TCP 443 convivono con reti che lasciano passare UDP senza problemi, e un solo server deve servire entrambe. Un profilo con proto udp risponde al secondo gruppo e fallisce sul primo, e modificare la stessa configurazione per dire proto tcp non crea un secondo listener. La direttiva sceglie un solo trasporto per un processo. Tutto il resto deriva da questo vincolo.
O esegui più di un processo, oppure esegui una versione che può associare più socket contemporaneamente.
Un processo associa un solo trasporto prima della 2.7
L'OpenVPN della comunità associa il socket descritto da proto, e quella direttiva sceglie un unico trasporto per l'istanza. TCP e UDP sono stack separati, quindi lo stesso numero di porta può essere occupato da entrambi contemporaneamente, ma non da un solo processo. La linea 2.6 offre quindi un trasporto per demone. OpenVPN 2.7 ha rimosso questo limite per i server, che possono associare più socket tramite più istruzioni --local in un unico processo.
Controlla la versione prima di progettare intorno a una delle due risposte, perché la disposizione 2.7 è un modello operativo diverso con una propria sintassi di configurazione. Una guida scritta per la 2.6 descrive due processi anche quando non lo dice.
Tre modi per eseguire due istanze
Con le interfacce TAP, esegui un'istanza per trasporto e metti in bridge i due dispositivi tap sull'host. Entrambi gli insiemi di clienti finiscono nello stesso dominio broadcast, il che consente a un solo pool di indirizzi di coprirli e mantiene funzionanti i protocolli che dipendono dal broadcast. Con TUN il bridge non è disponibile, quindi la divisione più semplice assegna a ogni istanza la propria sottorete e lascia che l'instradamento tenga separati i due insiemi di clienti. Una terza opzione mantiene un solo pool facendo chiamare a ogni istanza uno script learn-address che installa una rotta /32 per il client attraverso il dispositivo di quell'istanza.
Questa terza disposizione è quella che le persone chiedono e quella che richiede più attenzione, perché lo script diventa parte del percorso dei dati e deve gestire correttamente gli eventi di aggiunta, aggiornamento ed eliminazione.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
Tieni separate le due istanze
Ogni istanza ha anche bisogno di una porta o di un indirizzo separato, di un file di stato separato e di una destinazione di log separata. Due daemon che scrivono nello stesso file di stato producono un output illeggibile durante un incidente, che è esattamente quando ti serve. Se una seconda istanza associa un indirizzo specifico, quell'indirizzo deve esistere sull'host all'avvio del processo; altrimenti esce con un errore di binding prima di dire qualsiasi cosa sulle chiavi.
Nomina le unità e i profili in modo che il trasporto sia evidente dal nome del file. Il prossimo operatore non dovrebbe dover aprire una configurazione per sapere quale sia TCP.
Abbina il profilo al listener
Un server che esegue proto tcp si aspetta un profilo client con proto tcp-client, e un profilo che porta ancora proto udp contro quel listener va in timeout senza un errore su cui l'utente possa agire. Mantieni due profili se il deployment offre entrambi i trasporti, ed etichettali in modo che il supporto sappia quale è stato provato. Il solo numero di porta non descrive il trasporto.
Le regole del firewall seguono la stessa divisione: una regola per UDP 1194 non dice nulla su TCP 1194, e una regola per un indirizzo non copre l'altro listener.
Leggi prima la vista del server
Inizia con ss -lntup sul server e conferma che compaiano sia un listener TCP sia uno UDP. Poi collega un client di ciascun tipo e controlla l'output di stato per due voci con indirizzi distinti. Se i socket esistono e nessun client arriva, il percorso o il firewall stanno rifiutando i pacchetti prima che il daemon li veda.
Un socket che non compare mai è un problema di configurazione o di binding, e un socket che compare ma non registra mai una connessione è un problema di filtraggio. I due sembrano identici dal client, ed è per questo che la vista del server viene prima. Tieni presente che TCP porta il blocco di testa della coda, quindi offrirlo è una misura di raggiungibilità e non un miglioramento per i client con un percorso UDP pulito.