MULTI: indirizzo sorgente errato dal client: di chi era quell’indirizzo?
L’origine interna non corrisponde al client che l’ha consegnata. Abbinala a un’assegnazione di tunnel, a una LAN dietro il client o a un’identità duplicata.
Il registro del server stampa MULTI: bad source address from client, scarta il pacchetto e la sessione resta connessa. Questa combinazione confonde chi legge il messaggio come un errore di autenticazione. Non lo è: il client si è autenticato e il pacchetto arrivato portava un indirizzo sorgente interno che il server non è riuscito ad associare a quell’istanza del client. Il controllo avviene prima della consegna, ed è per questo che il tunnel sembra sano mentre nulla di utile lo attraversa.
Cosa confronta il server prima della consegna
Per ogni pacchetto che arriva da un client, il server in spazio utente guarda l’indirizzo sorgente dentro il tunnel e chiede al proprio stato di instradamento interno a quale client appartenga quell’indirizzo. Se il proprietario è un’altra istanza, o non esiste alcun proprietario, il pacchetto viene scartato e l’avviso viene emesso.
La consegna ordinaria attraverso l’interfaccia del tunnel non avviene mai.
Quest’ordine spiega un dettaglio che lascia perplessi: i contatori del firewall dell’host non si muovono, perché il pacchetto non ha mai raggiunto il firewall. Regolare il filtraggio del percorso inverso sull’host non cambia nulla qui, dato che il rifiuto è avvenuto nel controllo di associazione del demone stesso. Leggi il messaggio come un’affermazione sulla proprietà, poi scopri quale delle tre situazioni l’ha prodotto.
Tre origini di un indirizzo interno non corrispondente
Il client potrebbe inviare da un indirizzo che non gli è stato assegnato, da una rete che nessuno ha dichiarato come sua, o da una copia di un’identità che ha già un proprietario. Tutte e tre producono la stessa riga di registro. Differiscono in ciò che devi cambiare. Parti dall’indirizzo e dall’elenco delle assegnazioni attuali, e lascia che questi due fatti scelgano il caso.
Distinguerle richiede due fatti: l’indirizzo rifiutato nel registro e le assegnazioni che il server ritiene attuali. Il secondo è disponibile dalla vista di stato o di gestione dell’istanza in esecuzione, ed è l’unica autorità che valga la pena consultare, perché un file di configurazione registra intenzioni e non lo stato presente.
Annota entrambi prima di cambiare qualcosa, poi classifica. Uno screenshot scattato dopo non è la registrazione dello stato che ha prodotto l’avviso. Conserva anche la marca temporale, perché le assegnazioni si spostano tra le sessioni.
| 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 dietro un client e iroute
Quando un client di sede instrada la propria rete privata, quella rete va dichiarata come appartenente al client. Un file specifico del client con una voce iroute lo fa, e la voce nomina il prefisso che il client può trasportare.
Una rotta del kernel che punta lo stesso prefisso al tunnel è un requisito separato, e aggiungerla non cambia nulla della proprietà interna del demone.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Verifica che l’identità effettiva corrisponda al nome del file, poiché una discrepanza significa che il file non viene mai caricato e il sintomo è identico a una voce assente. Non aggiungere un iroute ampio per zittire l’avviso, perché ciò trasforma un’origine inattesa in una autorizzata senza rispondere al perché il client l’abbia inviata. Il manuale di OpenVPN 2.6 documenta iroute, duplicate-cn e la mappatura delle identità come controlli separati.
La stessa identità su due macchine
Un profilo copiato su un secondo portatile porta lo stesso certificato e lo stesso nome comune. A seconda delle impostazioni del server, la connessione più recente può sostituire quella più vecchia, e l’istanza che detiene la proprietà vince il controllo di associazione.
Ciò fa sembrare il guasto intermittente e lo fa comparire solo quando entrambi i dispositivi sono svegli.
Consentire nomi comuni duplicati lascia che entrambi si connettano, ma non dà loro indirizzi statici indipendenti né proprietà indipendente. Se due dispositivi devono coesistere, registrali separatamente in modo che ciascuno abbia la propria identità e la propria assegnazione. Trattare l’impostazione dei duplicati come riparazione di questo avviso lascia il mistero al suo posto e ne aggiunge un secondo.
Dimostra che l’associazione è cambiata
Applica la correzione tramite il proprietario della configurazione, poi riconnetti il client interessato perché la nuova politica venga caricata.
Ripeti lo stesso flusso e conferma tre cose: l’origine interna del pacchetto, l’istanza del client a cui il server lo associa e il comportamento della destinazione in seguito.
Se l’avviso si ferma ma l’applicazione continua a fallire, il problema si è spostato invece di sparire. L’inoltro, le regole del firewall e il percorso di ritorno sono fasi separate, e superare il controllo di associazione significa solo che al pacchetto è stato permesso di lasciare il tunnel.