MULTI: adreça d’origen incorrecta del client: de qui era aquesta adreça?
L’origen intern no coincideix amb el client que l’ha lliurat. Encara-lo amb una assignació de túnel, una LAN darrere del client o una identitat duplicada.
El registre del servidor imprimeix MULTI: bad source address from client, descarta el paquet i la sessió continua connectada. Aquesta combinació confon qui llegeix el missatge com una fallada d’autenticació. No ho és: el client s’ha autenticat i el paquet que ha arribat portava una adreça d’origen interna que el servidor no ha pogut associar amb aquesta instància del client. La comprovació passa abans del lliurament, i per això el túnel sembla sa mentre no hi passa res d’útil.
Què compara el servidor abans del lliurament
Per a cada paquet que arriba d’un client, el servidor en espai d’usuari mira l’adreça d’origen dins del túnel i pregunta al seu estat d’encaminament intern a quin client pertany aquesta adreça. Si el propietari és una altra instància, o no n’hi ha cap, el paquet es descarta i s’emet l’avís.
El lliurament ordinari per la interfície del túnel no passa mai.
Aquest ordre explica un detall que desconcerta: els comptadors del tallafoc de l’amfitrió no es mouen, perquè el paquet no ha arribat mai al tallafoc. Ajustar el filtratge de ruta inversa a l’amfitrió no canvia res aquí, ja que el rebuig ha passat a la comprovació d’associació del dimoni. Llegeix el missatge com una afirmació sobre la propietat i després esbrina quina de les tres situacions l’ha produïda.
Tres orígens d’una adreça interna que no coincideix
El client pot estar enviant des d’una adreça que no li han assignat, des d’una xarxa que ningú no ha declarat com a seva, o des d’un duplicat d’una identitat que ja té propietari. Les tres produeixen la mateixa línia de registre. Es diferencien en què has de canviar. Comença per l’adreça i la llista d’assignacions actuals, i deixa que aquests dos fets triïn el cas.
Distingir-les requereix dos fets: l’adreça rebutjada al registre i les assignacions que el servidor considera actuals. El segon és disponible a la vista d’estat o de gestió de la instància en funcionament, i és l’única autoritat que val la pena consultar, perquè un fitxer de configuració registra intencions i no l’estat present.
Anota tots dos abans de canviar res i després classifica. Una captura de pantalla feta després no és un registre de l’estat que va produir l’avís. Guarda també la marca de temps, perquè les assignacions es mouen entre sessions.
| 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 |
La LAN darrere d’un client i iroute
Quan un client de seu encamina la seva pròpia xarxa privada, cal declarar aquesta xarxa com a pertanyent al client. Un fitxer específic del client amb una entrada iroute ho fa, i l’entrada anomena el prefix que el client pot transportar.
Una ruta del nucli que apunta el mateix prefix al túnel és un requisit a part, i afegir-la no canvia res de la propietat interna del dimoni.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Confirma que la identitat efectiva coincideix amb el nom del fitxer, ja que una discrepància vol dir que el fitxer no es carrega mai i el símptoma és idèntic a una entrada absent. No afegeixis un iroute ampli per silenciar l’avís, perquè això converteix un origen inesperat en un d’autoritzat sense respondre per què el client l’ha enviat. El manual d’OpenVPN 2.6 documenta iroute, duplicate-cn i el mapatge d’identitat com a controls separats.
La mateixa identitat en dues màquines
Un perfil copiat a un segon portàtil porta el mateix certificat i el mateix nom comú. Segons la configuració del servidor, la connexió més nova pot substituir la més antiga, i la instància que té la propietat guanya la comprovació d’associació.
Això fa que la fallada sembli intermitent i només aparegui quan tots dos dispositius són desperts.
Permetre noms comuns duplicats deixa que tots dos es connectin, però no els dona adreces estàtiques independents ni propietat independent. Si dos dispositius han de conviure, enregistra’ls per separat perquè cadascun tingui la seva identitat i la seva assignació. Tractar el paràmetre de duplicats com una reparació d’aquest avís deixa el misteri al lloc i n’afegeix un segon.
Demostra que l’associació ha canviat
Aplica la correcció a través del propietari de la configuració i després reconnecta el client afectat perquè es carregui la nova política.
Repeteix el mateix flux i confirma tres coses: l’origen intern del paquet, la instància del client amb què el servidor l’associa i el comportament de la destinació després.
Si l’avís s’atura però l’aplicació encara falla, el problema s’ha mogut en lloc de desaparèixer. El reenviament, les regles del tallafoc i la ruta de tornada són etapes separades, i passar la comprovació d’associació només vol dir que el paquet ha pogut sortir del túnel.