L'adattatore OpenVPN lampeggia su Windows? Controllate la presenza di un IP duplicato

Su Windows, un adattatore OpenVPN che prende un indirizzo, lo lascia cadere e lo ripete ogni pochi secondi di solito non è un bug DHCP. All'adattatore viene detto di usare un indirizzo a cui qualcos'altro risponde già, quindi Windows lo contrassegna come inutilizzabile e il client ricomincia. Il log del client resta silenzioso perché il conflitto viene risolto sotto di esso, dentro lo stack di rete del sistema operativo stesso.

Questa distinzione conta, perché ogni passo di diagnosi rivolto alla configurazione del tunnel mancherà un indirizzo duplicato sul lato server.

Iniziate dal registro eventi di Windows, non dal log del client

Windows registra i conflitti di indirizzi nel registro di sistema, con gli ID evento 4198 e 4199. Il primo segnala un conflitto rilevato per un indirizzo, il secondo segnala che un'interfaccia non ha potuto usare l'indirizzo con cui era configurata. Nessuno dei due menziona OpenVPN, ed è proprio per questo che è facile trascurarli.

Estraete gli eventi recenti e confrontate le loro marche temporali con il ciclo di rinnovo dell'adattatore: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Un conflitto ogni quindici secondi corrisponde a un client che ritenta lo stesso indirizzo contro un proprietario che continua a rispondere. Un solo conflitto al momento della connessione indica invece una collisione una tantum. In ogni caso, la domanda successiva è chi altro detiene l'indirizzo.

Tre disposizioni mettono due host su un solo indirizzo

Chiedete al server chi secondo lui detiene l'indirizzo, poi chiedete alla rete chi vi risponde. grep -H ifconfig-push /etc/openvpn/ccd/* elenca ogni indirizzo di tunnel appuntato e il certificato a cui appartiene. ip -4 neigh show dev tap0 mostra cosa ha appreso il bridge al secondo livello. Confrontare questi due elenchi trova la maggior parte dei duplicati in meno di un minuto.

Tre disposizioni spiegano quasi tutti i casi: una voce di client-config-dir appunta un indirizzo per due certificati, un segmento tap in bridge assegna a una macchina un indirizzo che un altro host possiede già staticamente, oppure un file di lease scaduto restituisce un indirizzo che un client ancora connesso crede di possedere. Il terzo caso è il più subdolo, perché ifconfig-pool-persist riutilizza deliberatamente gli indirizzi per i client noti.

Rendete l'indirizzo unico invece di gareggiare per esso

L'ordine di avvio decide solo chi vince oggi, quindi trattate come temporanea qualsiasi correzione basata sulla sequenza di riavvio. Date a ogni client la propria riga ifconfig-push, oppure assegnate indirizzi statici da un intervallo che nessuna interfaccia di bridge o server tocca. Controllate anche l'elenco dei client per nomi comuni duplicati, perché duplicate-cn permette a due sessioni di condividere un'identità e quindi un indirizzo appuntato. Se un dispositivo in bridge ha davvero bisogno di un indirizzo fisso, spostatelo nella sua sottorete o prenotatelo dal pool in un punto che il server registra.

Eliminate il file persist solo dopo aver saputo quali lease contiene, altrimenti la prossima riconnessione distribuirà di nuovo gli stessi indirizzi.

Riavviate nell'ordine giusto e confermate un solo proprietario per indirizzo

Applicate la modifica prima sul server, poi riconnettete i client, così ogni partecipante si registra contro il pool corretto. Riavviare prima i client li lascia con indirizzi che il server crede ancora occupati. Dopo il riavvio, leggete il file di stato e confermate che ogni nome comune compaia una volta con un indirizzo. Due voci per un nome significano che una vecchia sessione non è mai stata chiusa, non che il pool sia rotto.

Se un client continua a non riuscire a mantenere il proprio indirizzo, verificate se lo porta un'interfaccia di bridge sullo stesso host. Un bridge che ha ereditato un indirizzo da un dispositivo del fornitore risponderà ARP per esso anche quando il server VPN ha già consegnato quell'indirizzo a un client.

Osservate per un ciclo di rinnovo completo prima di chiudere il ticket

Una sola lettura pulita non dimostra nulla. Osservate l'adattatore almeno dieci minuti e forzate una riconnessione a metà: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. L'indirizzo dovrebbe sopravvivere alla riconnessione e restare in uno stato preferito.

Poi rieseguite la query degli eventi del primo passo e confermate che non restituisce nulla di nuovo. Un log silenzioso attraverso una riconnessione è la prova che il conflitto è sparito, mentre un log silenzioso dopo una sola connessione significa solo che la corsa non è ancora avvenuta. Infine, provate la risorsa per cui esiste il tunnel, perché un bridge che ha perso il proprio indirizzo può rompere un percorso del fornitore mentre la VPN stessa sembra sana.

Annotate l'intervallo del pool, ogni indirizzo appuntato e l'host che lo possiede nelle note del server. La prossima collisione si individua allora in pochi minuti invece di richiedere un intero pomeriggio per essere riscoperta.