¿Puede este complemento de NetworkManager ejecutar dos VPN a la vez?

En la lista de conexiones hay dos entradas VPN, ambas dicen conectado y solo una transporta el tráfico que esperaba. O la segunda se niega a arrancar y nadie puede decir si el problema es el complemento, el cliente o una política que olvidó. Las afirmaciones sobre un límite de una sola VPN describen implementaciones concretas, y las implementaciones difieren. Recorra primero la capacidad y después la coordinación.

Cuente los perfiles guardados y luego las activaciones

Un perfil guardado es un objeto de configuración y una conexión activa es una instancia en ejecución. La lista fusiona visualmente ambos conceptos, por eso los dos informes suenan ciertos. Empiece nombrando los objetos exactos con sus UUID, porque el nombre mostrado no es único y una importación antigua suele compartir etiqueta con una entrada más reciente. Después revise la lista de activos por separado y vea qué UUID aparecen. Solo entonces sabrá si compara dos configuraciones o dos túneles vivos.

Activar el mismo UUID dos veces es un tercer caso y no es concurrencia. Es una reactivación de una sola instancia.

Lea los metadatos propios del complemento

Cada complemento VPN incluye un pequeño archivo de metadatos que el gestor lee, y esos archivos pueden declarar si el complemento admite varias conexiones a la vez. Lea el archivo instalado en esta máquina en lugar de repetir lo que escribe ahora un proyecto upstream, porque el paquete de la distribución decide qué tiene realmente. La misma comprobación vale por protocolo: una respuesta para un complemento no dice nada sobre otro. Anote la versión del paquete junto al resultado, para que una comparación posterior signifique algo.

Los consejos antiguos sobre un límite de una sola VPN describían integraciones más antiguas. No es ni siempre cierto ni seguro darlo por fijo, y el archivo que tiene delante lo resuelve localmente.

Concurrente no es coordinado

Que dos complementos arranquen con éxito demuestra la capacidad, no el diseño. Dos túneles que ofrecen una ruta por defecto competirán, y el que instaló su ruta en último lugar suele ganar sin anunciarlo. Los rangos privados solapados tienen el mismo problema en menor escala.

Decida qué destinos pertenecen a cada perfil antes de activar nada. Cambiar el nombre de un perfil no distingue los destinos.

El DNS elige un ganador lo haga usted o no

La configuración del resolutor es por perfil, y cuando hay dos activos el orden de resolución lo deciden la política y la prioridad, no la intención. El perfil que subió último puede poseer en silencio todos los nombres corporativos.

Asigne cada espacio de nombres privado al resolutor que debe responder por él y fije la preferencia de enrutamiento a propósito en lugar de confiar en el orden. Luego pruebe un nombre de cada espacio con los dos túneles levantados, y de nuevo con uno de ellos desconectado. Un resolutor que solo funciona mientras ambos túneles están arriba es un diseño que sorprenderá a alguien en el peor momento posible.

Despliegue en un orden fijo e inspeccione entre pasos

Active un perfil, inspeccione el estado de sus rutas y del resolutor, después active el segundo y vuelva a inspeccionar. Comparar los dos estados le dice qué cambió y qué perfil posee qué. No active ambos y luego diagnostique el resultado.

Pruebe cada recurso necesario a través del túnel que debe transportarlo, luego desconecte un perfil y confirme que el otro conserva sus rutas, su DNS y su comportamiento de fallo previsto. Si el complemento desplegado de verdad no puede hacer lo que necesita, elija una actualización compatible o una alternativa explícitamente aislada en lugar de revivir un protocolo obsoleto junto al gestor. Un segundo túnel separado que nadie gestiona no es aislamiento; es otra fuente de rutas sorprendentes.