¿Qué componente posee realmente un límite de rutas de OpenVPN?
Un límite de rutas puede pertenecer al motor de OpenVPN, al complemento de NetworkManager o al servidor. Nombre al propietario antes de editar un perfil o subir un número.
Un perfil con doscientas rutas funciona en una máquina e instala cuarenta en otra. El motor, la integración que lo arranca y el servidor que lo alimenta tienen voz, y cada uno puede detener la lista en un punto distinto. Leer el fallo como un solo límite te lleva al archivo equivocado. El mecanismo tiene tres etapas, y la etapa que se detuvo deja pruebas visibles cuando sabes qué buscar.
Tres etapas, tres límites distintos
Primero el motor analiza la opción y decide si esta versión la entiende. Después la integración instala lo que el motor informa, y su propio código puede limitar o remodelar la lista. Por último el servidor decide cuántas rutas enviará a una identidad concreta, antes de que ninguna etapa del cliente vea nada. Tres etapas, tres techos, y solo uno de ellos es el número del perfil.
Subir un techo no hace nada por los demás. Una ruta enviada y rechazada puede ser una decisión de política en el servidor, un solapamiento que el cliente resolvió, o un límite del instalador que descartó el exceso. Cada uno de esos casos tiene una solución distinta.
Separa los tres antes de medir nada. Un error del analizador nombra un testigo, un límite del instalador deja una tabla de rutas corta, y una decisión de política no deja absolutamente nada. Las pruebas te dicen qué etapa inspeccionar primero.
| Stage | Who decides | What you can see |
|---|---|---|
| Parse | Client engine | An error naming the option |
| Install | Activation owner | A route count below the pushed count |
| Offer | Server policy | A route absent from the pushed list |
El analizador habla primero
Una opción desconocida falla ruidosamente y pronto, y el texto del error nombra el testigo. Esa es la etapa más fácil de identificar: compara el mensaje exacto con la versión instalada del motor, porque una opción añadida en una versión es desconocida en la anterior. Un perfil copiado de un despliegue más nuevo es la causa habitual de ese desajuste. El analizador nunca ignora en silencio una directiva que no reconoce.
Una opción aceptada no dice nada sobre el resultado. El análisis tiene éxito, y la lista aún puede quedar recortada por el instalador o no ser ofrecida nunca por el servidor. Trata un análisis limpio como permiso para continuar, no como prueba.
Anota la cadena de versión del binario que realmente se ejecutó, no de la idea que tiene el gestor de paquetes de lo que está instalado. Esos dos discrepan más a menudo de lo que se espera.
El instalador tiene su propio techo
El componente que posee la activación puede ser un complemento de NetworkManager en lugar del binario del motor, y puede imponer su propio límite antes de que exista cualquier túnel. Su editor puede mostrar un campo que el motor en marcha nunca lee, o leer un campo que el editor no muestra. Ambas situaciones parecen un fallo del cliente desde fuera. Ninguna se corrige editando el perfil.
Cuenta lo que llegó en lugar de lo que se configuró. La orden ip route show dev tun0 lista las rutas instaladas, y comparar ese recuento con la lista enviada separa una ruta descartada de una que nunca se envió. Un recuento que coincide con el envío devuelve la sospecha al servidor.
Una capa de shell alrededor del binario del motor para forzar un número mayor difumina las actualizaciones y convierte la reversión en una adivinanza. También oculta el límite real a quien lea la configuración después.
El servidor decide qué te ofrecieron
La política por cliente puede reducir la lista antes de que se transmita. Un archivo específico del cliente puede añadir rutas para una identidad, o una política de grupo puede omitirlas, y el cliente no puede distinguir una ruta filtrada de una que nunca se definió. Esa ambigüedad es la razón por la que importa el registro del servidor. Pide la lista efectiva de envío para esa identidad, no la plantilla.
Compara el registro del servidor con la lista recibida. La brecha entre ambos es la capa de política, y suele ser menor de lo que el perfil sugiere.
Cuando el diseño lo permite, resume las redes contiguas y borra las entradas obsoletas. Menos rutas y más grandes resuelven más casos que un techo más alto.
Cambia el número en el lugar correcto
Usa el ajuste documentado del componente que realmente posee el límite. Si el campo falta en el complemento, comprueba si el complemento es anterior a la función o si otro fondo posee las rutas. Después documenta las versiones del motor, del complemento y del servidor junto al valor que elegiste. La siguiente actualización reabre la pregunta, y la nota es lo que permite responderla.
Vuelve a probar tras cualquier actualización de cualquiera de los tres. Un límite subido en el lugar correcto se mueve igualmente cuando cambia el componente que lo aplica. El registro de versiones es lo único que hace predecible ese movimiento.