MULTI: enderezo de orixe incorrecto do cliente: de quen era ese enderezo?
A orixe interna non coincide co cliente que a entregou. Emparella con unha asignación de túnel, unha LAN detrás do cliente ou unha identidade duplicada.
O rexistro do servidor imprime MULTI: bad source address from client, descarta o paquete e a sesión segue conectada. Esa combinación confunde a quen le a mensaxe como un fallo de autenticación. Non o é: o cliente autenticouse e o paquete que chegou levaba un enderezo de orixe interno que o servidor non puido asociar con esa instancia do cliente. A comprobación ocorre antes da entrega, e por iso o túnel parece san mentres nada útil o atravesa.
Que compara o servidor antes de entregar
Para cada paquete que chega dun cliente, o servidor en espazo de usuario mira o enderezo de orixe dentro do túnel e pregunta ao seu estado interno de encamiñamento a que cliente pertence ese enderezo. Se o propietario é outra instancia, ou non hai propietario ningún, o paquete descártase e emítese o aviso.
A entrega ordinaria pola interface do túnel nunca ocorre.
Esa orde explica un detalle que desconcerta: os contadores da devasa do host non se moven, porque o paquete nunca chegou á devasa. Axustar o filtrado de ruta inversa no host non cambia nada aquí, xa que o rexeitamento ocorreu na comprobación de asociación do propio demonio. Le a mensaxe como unha afirmación sobre a propiedade e logo descobre cal das tres situacións a produciu.
Tres orixes dun enderezo interno que non coincide
O cliente pode estar enviando desde un enderezo que non se lle asignou, desde unha rede que ninguén declarou como súa, ou desde un duplicado dunha identidade que xa ten propietario. As tres producen a mesma liña de rexistro. Diferéncianse no que hai que cambiar. Empeza polo enderezo e pola lista de asignacións actuais, e deixa que eses dous feitos escollan o caso.
Distinguilas require dous feitos: o enderezo rexeitado no rexistro e as asignacións que o servidor considera actuais. O segundo está dispoñible na vista de estado ou de xestión da instancia en execución, e é a única autoridade que paga a pena consultar, porque un ficheiro de configuración rexistra intencións e non o estado presente.
Anota ambos antes de cambiar nada e logo clasifica. Unha captura de pantalla tomada despois non é un rexistro do estado que produciu o aviso. Garda tamén a marca de tempo, porque as asignacións móvense entre sesións.
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
A LAN detrás dun cliente e iroute
Cando un cliente de sede encamiña a súa propia rede privada, esa rede debe declararse como pertencente ao cliente. Un ficheiro específico do cliente cunha entrada iroute fai iso, e a entrada nomea o prefixo que o cliente pode transportar.
Unha ruta do núcleo que apunta o mesmo prefixo ao túnel é un requisito aparte, e engadila non cambia nada da propiedade interna do demonio.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Confirma que a identidade efectiva coincide co nome do ficheiro, xa que unha discrepancia significa que o ficheiro nunca se carga e o síntoma é idéntico a unha entrada ausente. Non engadas un iroute amplo para silenciar o aviso, porque iso converte unha orixe inesperada nunha autorizada sen responder por que o cliente o enviou. O manual de OpenVPN 2.6 documenta iroute, duplicate-cn e o mapeado de identidade como controis separados.
A mesma identidade en dúas máquinas
Un perfil copiado a un segundo portátil leva o mesmo certificado e o mesmo nome común. Segundo a configuración do servidor, a conexión máis nova pode substituír a máis antiga, e a instancia que ten a propiedade gaña a comprobación de asociación.
Iso fai que o fallo pareza intermitente e só apareza cando ambos os dispositivos están espertos.
Permitir nomes comúns duplicados deixa que ambos se conecten, pero non lles dá enderezos estáticos independentes nin propiedade independente. Se dous dispositivos deben convivir, rexístranos por separado para que cada un teña a súa propia identidade e a súa propia asignación. Tratar o axuste de duplicados como unha reparación deste aviso deixa o misterio no seu sitio e engade un segundo.
Demostra que a asociación cambiou
Aplica a corrección a través do propietario da configuración e logo reconecta o cliente afectado para que se cargue a nova política.
Repite o mesmo fluxo e confirma tres cousas: a orixe interna do paquete, a instancia do cliente coa que o servidor o asocia e o comportamento do destino despois.
Se o aviso se detén pero a aplicación segue fallando, o problema moveuse en lugar de desaparecer. O reenvío, as regras da devasa e a ruta de volta son etapas separadas, e pasar a comprobación de asociación só significa que ao paquete se lle permitiu saír do túnel.