MULTI: dirección de origen incorrecta del cliente: ¿de quién era esa dirección?

El registro del servidor imprime MULTI: bad source address from client, descarta el paquete y la sesión sigue conectada. Esa combinación confunde a quien lee el mensaje como un fallo de autenticación. No lo es: el cliente se autenticó y el paquete que llegó llevaba una dirección de origen interna que el servidor no pudo asociar con esa instancia del cliente. La comprobación ocurre antes de la entrega, y por eso el túnel parece sano mientras nada útil lo atraviesa.

Qué compara el servidor antes de entregar

Para cada paquete que llega de un cliente, el servidor en espacio de usuario mira la dirección de origen dentro del túnel y pregunta a su estado interno de enrutamiento a qué cliente pertenece esa dirección. Si el propietario es otra instancia, o no hay propietario alguno, el paquete se descarta y se emite el aviso.

La entrega ordinaria por la interfaz del túnel nunca ocurre.

Ese orden explica un detalle que desconcierta: los contadores del cortafuegos del host no se mueven, porque el paquete nunca llegó al cortafuegos. Ajustar el filtrado de ruta inversa en el host no cambia nada aquí, ya que el rechazo ocurrió en la comprobación de asociación del propio demonio. Lee el mensaje como una afirmación sobre la propiedad y luego averigua cuál de las tres situaciones lo produjo.

Tres orígenes de una dirección interna que no coincide

El cliente puede estar enviando desde una dirección que no se le asignó, desde una red que nadie declaró como suya, o desde un duplicado de una identidad que ya tiene propietario. Las tres producen la misma línea de registro. Difieren en lo que hay que cambiar. Empieza por la dirección y la lista de asignaciones actuales, y deja que esos dos hechos elijan el caso.

Distinguirlas requiere dos hechos: la dirección rechazada en el registro y las asignaciones que el servidor considera actuales. El segundo está disponible en la vista de estado o de gestión de la instancia en ejecución, y es la única autoridad que merece consultarse, porque un archivo de configuración registra intenciones y no el estado presente.

Anota ambos antes de cambiar nada y luego clasifica. Una captura de pantalla tomada después no es un registro del estado que produjo el aviso. Guarda también la marca de tiempo, porque las asignaciones se mueven entre sesiones.

La LAN detrás de un cliente y iroute

Cuando un cliente de sede enruta su propia red privada, esa red debe declararse como perteneciente al cliente. Un archivo específico del cliente con una entrada iroute lo hace, y la entrada nombra el prefijo que el cliente puede transportar.

Una ruta del núcleo que apunta el mismo prefijo al túnel es un requisito aparte, y añadirla no cambia nada de la propiedad interna del demonio.

# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0

Confirma que la identidad efectiva coincide con el nombre del archivo, ya que una discrepancia significa que el archivo nunca se carga y el síntoma es idéntico a una entrada ausente. No añadas un iroute amplio para silenciar el aviso, porque eso convierte un origen inesperado en uno autorizado sin responder por qué el cliente lo envió. El manual de OpenVPN 2.6 documenta iroute, duplicate-cn y el mapeo de identidad como controles separados.

La misma identidad en dos máquinas

Un perfil copiado a un segundo portátil lleva el mismo certificado y el mismo nombre común. Según la configuración del servidor, la conexión más nueva puede reemplazar a la más antigua, y la instancia que tiene la propiedad gana la comprobación de asociación.

Eso hace que el fallo parezca intermitente y solo aparezca cuando ambos dispositivos están despiertos.

Permitir nombres comunes duplicados deja que ambos se conecten, pero no les da direcciones estáticas independientes ni propiedad independiente. Si dos dispositivos deben convivir, regístralos por separado para que cada uno tenga su propia identidad y su propia asignación. Tratar el ajuste de duplicados como una reparación de este aviso deja el misterio en su sitio y añade un segundo.

Demuestra que la asociación cambió

Aplica la corrección a través del propietario de la configuración y luego reconecta el cliente afectado para que se cargue la nueva política.

Repite el mismo flujo y confirma tres cosas: el origen interno del paquete, la instancia del cliente con la que el servidor lo asocia y el comportamiento del destino después.

Si el aviso se detiene pero la aplicación sigue fallando, el problema se movió en lugar de desaparecer. El reenvío, las reglas del cortafuegos y la ruta de vuelta son etapas separadas, y pasar la comprobación de asociación solo significa que al paquete se le permitió salir del túnel.