☰

Mejores prácticas para configurar múltiples instancias de OpenVPN para diferentes clientes

tag-icon • tag-icon linux vpn openvpn pki
Mejores prácticas para configurar múltiples instancias de OpenVPN para diferentes clientes

Estoy trabajando en un proyecto en el que necesito configurar instancias de OpenVPN para conectar dispositivos IoT de varios clientes a un servidor central. Cada cliente debe tener su propia conexión VPN aislada. Actualmente estoy planificando la infraestructura y el manejo de certificados y me gustaría recibir consejos sobre el mejor enfoque.

Para el manejo de certificados, estoy considerando la siguiente estructura:

CA.crt
|_Customer1.crt
|  |_ServerCert.crt
|     |_ClientCert1.crt
|     |_ClientCert2.crt
|     |_ClientCertX.crt
|
|_Customer2.crt
   |_ServerCert.crt
      |_ClientCert1.crt
      |_ClientCert2.crt
      |_ClientCertX.crt

Entonces, configuraría una instancia de OpenVPN separada para cada cliente, como /etc/openvpn/server/Client1/y /etc/openvpn/server/Client2/, y los iniciaría usando comandos como:

sudo systemctl start [email protected] ¿Es este un enfoque aceptable? Agradecería cualquier idea o sugerencia alternativa para organizar la infraestructura para múltiples clientes y servidores VPN.

Otras preguntas son:

  • ¿Cómo gestionar muchos dispositivos descentralizados, tal vez Ansible?
  • Para cada instancia de OpenVPN, necesito un puerto adicional.
    • Después de usar 443 TCP,UDP y 1194 TCP,UDP, ¿qué sigue?

¡Gracias!

Respuesta1

El manual de OpenVPN indica que confiará en cualquier certificado que sea descendiente del certificado de CA que configuró en él. Entonces, para separar realmente las VPN, omite el certificado raíz de todas las configuraciones. No se utilizará en ninguna parte, no añade valor ni beneficio, así que ¿por qué molestarse en mantenerlo? Simplemente tome EasyRSA y cree una CA "raíz de un solo nivel" separada e independiente para cada VPN.

No sé por qué incluyeste el puerto 443 aquí; Rara vez se usa para OpenVPN porque es un puerto HTTPS bien conocido y a menudo está ocupado, por lo que cuando se usa, a menudo se trata de configuraciones complicadas que involucran port-share. En ese caso, sslhes superior, al menos porque puede usar su "modo transparente" para que los demonios vean la IP real del control remoto y no preocuparse por la forma en que OpenVPN hace que esa información esté disponible. Aunque dudo que necesites esta peculiaridad para tu proyecto. Aparte de eso, realmente puedes usar números de puerto arbitrarios. 1194 aparece como "oficial", pero nada le prohíbe configurar 11941, 1195 o 5000 (lo que se sugirió hace quince años) o cualquier otra cosa. Elija un conjunto de puertos, digamos desde 1194 en adelante, y simplemente agregue uno para cada instancia de VPN sucesiva.

El resto es correcto: utiliza puertos separados (públicos) para demonios independientes y los ejecuta como unidades SystemD separadas. Considere contenedores separados para diferentes VPN: si bien es posible ejecutar instancias de VPN separadas en un único espacio de nombres, es más fácil y menos propenso a errores simplemente dividirlas (y no consume muchos más recursos). Según tengo entendido, sus clientes son entidades no relacionadas, por lo que esta sería una forma más sencilla de separarlos. En ese caso, las configuraciones de VPN dentro de los contenedores pueden usar el puerto predeterminado, pero usted reenviará (publicará) puertos diferentes para ellos.

Designar algún sistema únicamente para administrar VPN; almacenará sus CA y, por lo tanto, solo él podrá emitir certificados. Ese sistema también será necesario para emitir CRL; De forma predeterminada, las CRL tienen una duración de 30 días y, si las configura crl-verify(¡lo hará!), cuando la CRL caduque, la VPN dejará de aceptar nuevas conexiones hasta que vuelva a ser válida. Entonces, lo que realmente necesita automatizar es la reemisión y distribución de CRL. Al actualizar el archivo CRL, no es necesario volver a cargar el demonio, por lo que scpbasta con utilizar el archivo antiguo en el sistema de destino.

Es útil crear una plantilla de archivo de configuración de cliente OpenVPN y generar configuraciones de cliente con certificados integrados a partir de esa plantilla; eso me ahorró mucho tiempo incluso sin Ansible. A menudo personalizo archivos empaquetados openssl.cnfy varspara agregar varios campos y eliminar los no utilizados, y para reorganizar las cosas y que se ejecuten con menos preguntas (o sin preguntas, para el procesamiento por lotes). Para su caso, puede resultar útil tener dichas plantillas y scripts de generación para crear nuevas VPN y también configuraciones de servidor. Estas plantillas, scripts y personalizaciones serán útiles para los manuales de Ansible que crean instancias de un nuevo cliente o un nuevo dispositivo IoT de un cliente existente. Para este último, puede ser bueno vincular el CN ​​del certificado al número de serie del dispositivo IoT, lo que debería simplificar la contabilidad.

información relacionada