Access Server ha perso il binding dopo la rinomina di un’interfaccia di rete: correggete le chiavi

Avete rinominato un’interfaccia di rete, o ripristinato una macchina il cui adattatore è tornato con un altro nome, e ora il demone di OpenVPN Access Server non si avvia. L’interfaccia web potrebbe ancora rispondere o no, a seconda di quale componente era legato al vecchio nome. Il servizio non è corrotto e la configurazione non è persa; un’impostazione punta ancora a un’interfaccia che l’host non possiede più.

Il riflesso è reinstallare, reinizializzare o modificare il database finché l’errore non scompare. Ognuna è un cambiamento più grande del guasto, e l’ultima può cancellare gli utenti, i permessi e le dipendenze che rendevano il server degno di recupero. È un problema di binding, e ha una correzione con un nome.

Che cosa dice davvero il sintomo

Un demone che non riesce a fare binding di solito lo dice nel proprio registro: l’indirizzo non è disponibile o l’interfaccia non esiste. Il messaggio è preciso: nomina l’indirizzo provato; confrontatelo con ip -br addr sull’host per capire se l’interfaccia è stata rinominata, rimossa o alzata senza il vecchio indirizzo.

Tenete aperta una console di ripristino autorizzata per tutto il tempo. Se il binding che state per cambiare porta la vostra unica sessione amministrativa, vi siete tagliati la via del ritorno. Una console locale, un secondo indirizzo di gestione o un percorso out-of-band documentato rendono il cambio reversibile.

Interrogate la configurazione prima di modificarla

Access Server espone la configurazione tramite la propria CLI. La vista documentata è:

sacli ConfigQuery

Eseguitela nell’ambiente amministrativo documentato per la vostra versione, non da una shell estranea su un altro host. Salvate i valori attuali in un luogo protetto prima di cambiare qualcosa e non incollate l’output completo in un thread pubblico di supporto.

Quell’output è una vista della configurazione del server, non un backup completo. Le proprietà di utenti e gruppi si interrogano separatamente, quindi un binding pulito non ripristina le identità, e un’identità ripristinata non ripara un listener. Registrate entrambe come due artefatti separati.

Determinate quale listener è rotto

Access Server esegue più di un listener. I demoni OpenVPN portano il traffico del tunnel, il servizio web porta il portale di amministrazione e clienti, e altri componenti possono avere le proprie porte. Una richiesta del browser fallita non dice quale sia fallito, né il numero di porta nel messaggio di errore.

Le chiavi di binding del demone sono documentate per demone, e nel tutorial ufficiale il valore è l’identificatore dell’interfaccia anche se i nomi delle chiavi finiscono con ip_address. Leggete quella frase due volte. Il tutorial si aspetta anche che i demoni UDP e TCP condividano un’interfaccia, quindi correggere una sola chiave è una riparazione parziale.

Cambiate l’impostazione indicata, non le righe corrispondenti

Il tutorial documenta ConfigPut su chiavi specifiche, come vpn.daemon.0.server.ip_address e vpn.daemon.0.listen.ip_address. Usate il metodo proprio del prodotto con il nome della chiave e il nuovo valore, nella sintassi documentata per la vostra versione, e cambiate solo le chiavi del listener che avete diagnosticato.

Quello che non dovreste fare è cercare nel database ogni riga il cui valore è il vecchio nome dell’interfaccia e sostituirle tutte. Ciò presuppone che il vecchio nome comparisse solo nelle impostazioni del listener, cosa che lo schema non promette. Rende anche la modifica impossibile da rivedere.

Vale la pena rifiutare altre due tentazioni. Ripristinare un valore predefinito che ascolta su tutte le interfacce è una decisione di esposizione, non una correzione ortografica; il binding locale previsto, il percorso pubblicato e il filtraggio davanti devono concordare con quella scelta. Reinizializzare la configurazione rinomina il problema invece di risolverlo, perché un’installazione nuova scarta proprio gli utenti e i permessi che funzionavano prima della rinomina.

Applicate e dimostrate che il percorso funziona

Corretto il valore, applicatelo tramite il ciclo di vita documentato del prodotto ( ciclo di vita ). Il tutorial usa sacli start dopo aver impostato le chiavi; non è un riavvio completo dell’host né un reset del database.

ss -lntup | grep -E '1194|443'
sacli ConfigQuery | grep -i ip_address

Controllate il listener, stabilite una connessione VPN autorizzata, raggiungete una risorsa privata e caricate la pagina amministrativa dal percorso atteso. Conservate i permessi e le revoche esistenti; un ripristino che li azzera ha corretto il binding e perso la distribuzione. Il lavoro è finito quando lo stesso servizio funziona sull’interfaccia prevista.