Servir OpenVPN por TCP y UDP desde un solo host
Antes de la 2.7, un proceso enlaza un solo transporte. Compare un par TAP puenteado, dos subredes TUN y un grupo compartido, y luego empareje cada perfil con su socket de escucha.
Las redes que solo permiten TCP 443 conviven con redes que dejan pasar UDP sin problemas, y un servidor tiene que atender a ambas. Un perfil con proto udp responde al segundo grupo y falla con el primero, y editar la misma configuración para decir proto tcp no crea un segundo socket de escucha. La directiva elige un transporte para un proceso. Todo lo demás se deriva de esa restricción.
O ejecuta más de un proceso, o ejecuta una versión que pueda enlazar varios sockets a la vez.
Antes de la 2.7, un proceso enlaza un transporte
La versión comunitaria de OpenVPN enlaza el socket que describe proto , y esa directiva elige un solo transporte para la instancia. TCP y UDP son pilas separadas, así que el mismo número de puerto puede estar ocupado por ambos a la vez, pero no por un solo proceso. Por eso la línea 2.6 le da un transporte por demonio. OpenVPN 2.7 eliminó esa limitación para los servidores, que pueden enlazar varios sockets mediante varias --local en un solo proceso.
Compruebe la versión antes de diseñar en torno a cualquiera de las dos respuestas, porque el montaje de la 2.7 es un modelo operativo distinto con su propia sintaxis de configuración. Una guía escrita para la 2.6 describe dos procesos aunque no lo diga.
Tres formas de ejecutar dos instancias
Con interfaces TAP, ejecute una instancia por transporte y puentee los dos dispositivos tap en el host. Ambos conjuntos de clientes acaban en el mismo dominio de difusión, lo que permite que un solo grupo de direcciones los cubra y mantiene funcionando los protocolos que dependen de la difusión. Con TUN no hay puente, así que la división más simple da a cada instancia su propia subred y deja que el enrutamiento mantenga separados los dos conjuntos de clientes. Una tercera opción conserva un solo grupo haciendo que cada instancia llame a un script learn-address que instala una ruta /32 para el cliente a través del dispositivo de esa instancia.
Ese tercer montaje es el que la gente pide y el que más cuidado requiere, porque el script pasa a formar parte de la ruta de datos y debe manejar correctamente los eventos de alta, actualización y borrado.
| 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 |
Mantenga las dos instancias separadas
Cada instancia también necesita un puerto o una dirección aparte, un archivo de estado aparte y un destino de registro aparte. Dos demonios que escriben en un mismo archivo de estado producen una salida que no se puede leer durante un incidente, que es justo cuando la necesita. Si una segunda instancia enlaza una dirección concreta, esa dirección debe existir en el host cuando arranca el proceso; si no, sale con un fallo de enlace antes de decir nada sobre claves.
Nombre las unidades y los perfiles de modo que el transporte sea evidente por el nombre del archivo . El siguiente operador no debería tener que abrir una configuración para saber cuál es TCP.
Empareje el perfil con el socket de escucha
Un servidor que ejecuta proto tcp espera un perfil de cliente con proto tcp-client , y un perfil que aún lleva proto udp contra ese socket de escucha agota el tiempo sin un error sobre el que el usuario pueda actuar . Mantenga dos perfiles si el despliegue ofrece ambos transportes, y etiquételos para que el soporte sepa cuál se probó. El número de puerto por sí solo no describe el transporte.
Las reglas del cortafuegos siguen la misma división: una regla para UDP 1194 no dice nada sobre TCP 1194, y una regla para una dirección no cubre el otro socket de escucha.
Lea primero la visión del servidor
Empiece con ss -lntup en el servidor y confirme que aparecen tanto un socket de escucha TCP como uno UDP. Después conecte un cliente de cada tipo y revise la salida de estado en busca de dos entradas con direcciones distintas. Si los sockets existen y no llega ningún cliente, la ruta o el cortafuegos rechaza los paquetes antes de que el demonio los vea.
Un socket que nunca aparece es un problema de configuración o de enlace, y un socket que aparece pero nunca registra una conexión es un problema de filtrado. Desde el cliente los dos parecen idénticos, por eso la visión del propio servidor va primero. Tenga en cuenta que TCP arrastra bloqueo de cabeza de línea, así que ofrecerlo es una medida de alcanzabilidad y no una mejora para clientes con una ruta UDP limpia.