RemoteEnable non è un accesso VPN: delimitare l’amministrazione di SoftEther

Il tutorial dice di eseguire RemoteEnable e poi di connettersi, e si legge come se quei due passaggi fossero lo stesso tipo di cosa. Non lo sono. RemoteEnable concede a un’altra macchina il permesso di amministrare il servizio client SoftEther VPN in esecuzione su questo computer. Connettersi è un account VPN che si autentica presso un server, e in ciò non è coinvolto alcun permesso di gestione.

Il mito: RemoteEnable accende la VPN

La confusione nasce dalla vicinanza. Una guida abilita l’amministrazione remota, riavvia il servizio client, poi si connette, e la connessione funziona dopo, così i due passaggi sembrano legati causalmente. Ciò che è realmente cambiato è chi può parlare con il servizio, non se il servizio può raggiungere un server. Disattivate l’amministrazione remota su un client configurato correttamente e la connessione VPN si stabilisce comunque.

L’aiuto del comando nel progetto originale è esplicito sulla portata: amministrazione remota tramite VPN Client Manager o vpncmd da fuori localhost. Nulla in quella descrizione menziona un tunnel, un account o una rotta. Il permesso concesso è una portata amministrativa, e il suo soggetto è il servizio client, non la connessione.

Tre identità che condividono la parola password

Le vecchie guide usano una sola parola per tre credenziali non correlate, ed è così che le distribuzioni finiscono con un segreto incollato nel campo sbagliato.

La password di amministrazione del servizio client protegge l’amministrazione del client SoftEther locale. La password dell’account VPN si autentica presso un server secondo la politica di quel server. Il certificato del server non è affatto una password, ma risponde a quale endpoint il client deve accettare. Cambiarne una non cambia le altre, e copiare un valore tra esse produce una configurazione diversa invece che più semplice.

L’opzione solo remoto sulla password di amministrazione merita un secondo sguardo, perché decide se il requisito della password vale anche per l’amministrazione dalla macchina locale. Restringere quella portata è una scelta deliberata per un portatile a utente singolo, non un aggiramento per una password che nessuno ha annotato.

Che cosa cambia davvero abilitando l’amministrazione remota

Ne derivano due conseguenze operative, ed entrambe sono facili da trascurare in una guida copia-incolla. Una password di amministrazione diventa obbligatoria appena si attiva l’amministrazione remota, e la nuova disponibilità entra in vigore solo dopo il riavvio del servizio client.

Quel riavvio è un’interruzione reale per tutto ciò che usa il client, quindi pianificatelo con chi possiede la macchina. Abilitare la funzione non apre nemmeno da sola un percorso nel firewall: il servizio deve comunque essere raggiungibile dalla stazione di amministrazione, e un firewall dell’host o un’ACL a monte possono renderlo irraggiungibile. Un servizio irraggiungibile non è prova che il permesso sia stato delimitato correttamente, solo che qualcos’altro lo blocca.

Scrivete il percorso di amministrazione previsto nelle note di distribuzione, inclusi la porta e l’intervallo di indirizzi che possono usarlo. Quella nota è anche il luogo in cui registrare chi ha chiesto la capacità e quando va revocata.

Decidete chi può amministrare questo client

Su un portatile di vostra proprietà, mantenete l’amministrazione sulla console locale a meno che non possiate nominare la macchina che necessita di accesso remoto e dire perché. Per un dispositivo amministrato centralmente, nominate l’amministratore, il percorso di amministrazione e il responsabile del ripristino prima di abilitare qualsiasi cosa. La domanda non è se la funzione sia comoda, ma chi risponde della configurazione che espone.

Eseguite i comandi sul servizio locale perché la modifica finisca nella vostra cronologia della shell e non in uno screenshot: vpncmd localhost /client /cmd RemoteDisable disattiva la capacità, e lo stesso comando con RemoteEnable la attiva. Riavviate il servizio dopo, altrimenti l’impostazione non sarà in vigore.

Se un tutorial la abilita come passo preliminare senza spiegazione, trattatelo come una domanda irrisolta e non come un’istruzione da seguire. Chiedete quale stazione di amministrazione dovrebbe usarla, e se non c’è risposta, lasciate la capacità disattivata.

Verificate separatamente l’accesso amministrativo e la connettività

Due test rispondono a due domande diverse, ed eseguirne solo uno è il modo in cui una distribuzione finisce con un’amministrazione remota che nessuno voleva.

vpncmd localhost /client /cmd RemoteDisable
systemctl restart vpnclient
vpncmd localhost /client /cmd AccountList
vpncmd localhost /client /cmd NicList

Le prime due righe riportano il client sotto amministrazione locale e applicano la modifica. Le ultime due confermano che gli account VPN e gli adattatori virtuali sono ancora configurati, come dovrebbero essere, perché la portata amministrativa e lo stato della connessione sono impostazioni indipendenti. Se l’elenco degli account torna vuoto dopo il riavvio, qualcos’altro si è rotto e l’impostazione di amministrazione remota non è la spiegazione.

Poi provate la connessione stessa dal client e confermate che l’adattatore conservi l’indirizzo e le rotte attese. Una sessione vpncmd riuscita dimostra una relazione di controllo e non dice nulla sull’uscita del traffico dal tunnel.