Servir OpenVPN por TCP e UDP desde un único host
Un proceso vincula un só transporte antes da 2.7. Compara un par TAP con ponte, dúas subredes TUN e unha reserva compartida, e despois axusta cada perfil ao seu listener.
As redes que só permiten TCP 443 conviven con redes que deixan pasar UDP sen problema, e un servidor ten que atender as dúas. Un perfil con proto udp responde ao segundo grupo e falla co primeiro, e editar a mesma configuración para dicir proto tcp non crea un segundo listener. A directiva escolle un só transporte para un proceso. Todo o demais deriva desa restrición.
Ou executas máis dun proceso, ou executas unha versión que pode vincular varios sockets á vez.
Un proceso vincula un só transporte antes da 2.7
O OpenVPN da comunidade vincula o socket que describe proto, e esa directiva escolle un único transporte para a instancia. TCP e UDP son pilas separadas, así que o mesmo número de porto pode estar ocupado polos dous á vez, pero non por un proceso. A liña 2.6 dálle por tanto un transporte por daemon. OpenVPN 2.7 eliminou esa limitación para os servidores, que poden vincular varios sockets mediante varias instrucións --local nun mesmo proceso.
Comproba a versión antes de deseñar arredor de calquera das dúas respostas, porque a disposición 2.7 é un modelo operativo distinto coa súa propia sintaxe de configuración. Unha guía escrita para a 2.6 describe dous procesos mesmo cando non o di.
Tres formas de executar dúas instancias
Con interfaces TAP, executa unha instancia por transporte e une os dous dispositivos tap cunha ponte no host. Os dous conxuntos de clientes acaban no mesmo dominio de difusión, o que permite que unha soa reserva de enderezos os cubra e mantén funcionando os protocolos que dependen da difusión. Con TUN a ponte non está dispoñible, así que a división máis simple dá a cada instancia a súa propia subrede e deixa que o encamiñamento manteña separados os dous conxuntos de clientes. Unha terceira opción mantén unha soa reserva facendo que cada instancia chame un script learn-address que instala unha ruta /32 para o cliente a través do dispositivo desa instancia.
Esa terceira disposición é a que a xente pide e a que require máis coidado, porque o script pasa a formar parte da ruta de datos e ten que xestionar correctamente os eventos de alta, actualización e baixa.
| 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 |
Mantén separadas as dúas instancias
Cada instancia tamén necesita un porto ou un enderezo distinto, un ficheiro de estado distinto e un destino de rexistro distinto. Dous daemons que escriben no mesmo ficheiro de estado producen unha saída que non se pode ler durante un incidente, que é exactamente cando a necesitas. Se unha segunda instancia vincula un enderezo concreto, ese enderezo ten que existir no host cando arranca o proceso; se non, sae cun fallo de vinculación antes de dicir nada sobre as chaves.
Nomea as unidades e os perfís de xeito que o transporte sexa evidente polo nome do ficheiro. O seguinte operador non debería ter que abrir unha configuración para saber cal é TCP.
Axusta o perfil ao listener
Un servidor que executa proto tcp espera un perfil de cliente con proto tcp-client, e un perfil que aínda leva proto udp contra ese listener caduca sen un erro sobre o que o usuario poida actuar. Mantén dous perfís se o despregamento ofrece os dous transportes, e etiquétaos para que o soporte saiba cal se probou. O número de porto por si só non describe o transporte.
As regras de cortalumes seguen a mesma división: unha regra para UDP 1194 non di nada sobre TCP 1194, e unha regra para un enderezo non cobre o outro listener.
Le primeiro a visión do servidor
Comeza con ss -lntup no servidor e confirma que aparecen tanto un listener TCP como un UDP. Despois conecta un cliente de cada tipo e revisa a saída de estado buscando dúas entradas con enderezos distintos. Se os sockets existen e non chega ningún cliente, a ruta ou o cortalumes están rexeitando os paquetes antes de que os vexa o daemon.
Un socket que nunca aparece é un problema de configuración ou de vinculación, e un socket que aparece pero nunca rexistra unha conexión é un problema de filtrado. Os dous ven idénticos desde o cliente, e por iso a visión do propio servidor vai primeiro. Ten en conta que TCP leva bloqueo de cabeza de liña, así que ofrecelo é unha medida de alcanzabilidade e non unha mellora para clientes cunha ruta UDP limpa.