OpenVPN su Windows: avviare il tunnel automaticamente e conservare le rotte

Qui si intrecciano due requisiti: il tunnel deve salire prima che chiunque acceda, e il traffico verso un secondo sito deve seguirlo. Sono problemi separati con meccanismi separati. L’avvio del servizio decide il primo, e la vita della rotta il secondo. Risolverne uno lascia l’altro esattamente dov’era.

Primo passo: mettete il profilo dove il servizio lo cerca

Il servizio Windows legge i profili da una directory fissa, e la GUI legge dallo stesso posto, quindi un profilo che funziona all’importazione può restare invisibile all’avvio. Mettete i file .ovpn nella directory config dell’installazione, che di solito si trova sotto Program Files. Un profilo lasciato nella cartella Downloads di un utente non rientra affatto nell’ambito del servizio.

Le indicazioni più vecchie puntano a una cartella config-auto, che alcune build dell’era 2.5 rispettavano e le versioni successive no. È per questo che un aggiornamento può trasformare un avvio automatico funzionante in silenzio, senza nulla nel registro sulle credenziali. Verificate quale directory legge davvero la build installata prima di spostare file.

Con più profili su una macchina, date a ciascuno un adattatore con nome tramite dev-node. Altrimenti competono per la stessa interfaccia e il secondo fallisce in un modo che sembra un problema di credenziali.

Secondo passo: avviate il servizio, non l’icona della barra delle applicazioni

Impostare il servizio OpenVPN su Automatic lo fa partire all’avvio senza accesso. È questo il meccanismo, e l’icona della barra non ne fa parte. Quando il servizio possiede la connessione, la GUI può non mostrare né icona né stato, il che è atteso e non un guasto.

La conseguenza è che disconnettere significa fermare il servizio, non fare clic su Disconnect. Ditelo a chi si occupa della macchina, altrimenti la prima chiamata al supporto riguarderà un’icona mancante.

Verificate che l’account del servizio possa leggere il profilo e il materiale della chiave. Un problema di permessi all’avvio nel registro sembra esattamente un errore di autenticazione.

Terzo passo: legate la rotta al tunnel

Una voce permanente è lo strumento sbagliato qui. Aggiungere una rotta con -P la fa sopravvivere ai riavvii e, peggio, la fa sopravvivere alla chiusura del tunnel. Con la VPN spenta, il prefisso punta ancora a un gateway che non c’è più, quindi l’host non raggiunge quella destinazione finché qualcuno non cancella la voce.

Tre alternative si comportano correttamente. Spingete la rotta dal server, che la aggiunge alla connessione e la rimuove alla disconnessione. Aggiungetela in uno script route-up che legge route_vpn_gateway, così il salto successivo viene dal tunnel negoziato. Oppure usate Add-VpnConnectionRoute con un profilo VPN nativo di Windows, che lega il prefisso a quella connessione.

Quando il server offre più di quanto serva a questo sito, route-nopull rifiuta le rotte spinte e lascia la tabella del tutto locale. Questo si adatta a un profilo condiviso i cui utenti non devono ricevere una rotta predefinita aziendale.

Quarto passo: sopravvivete a un avvio a freddo

Avviare il servizio prima che esista lo stack di rete produce un tentativo fallito e nessun nuovo tentativo. Impostarlo su Automatic (Delayed Start), o aggiungere una dipendenza dal servizio di rete, elimina quella corsa. Poi ripetete il test di avvio e verificate che un secondo tentativo non serva più.

Le modifiche a rotte e adattatori richiedono diritti di amministratore. Un collegamento di avvio per utente non li ha, quindi uno script che funziona da una shell elevata può non fare nulla in silenzio all’accesso. Programmatelo come attività con i privilegi più alti, o lasciate che il servizio si occupi della modifica. Poi provatelo come l’utente che accederà davvero.

Provate la sequenza che distribuite davvero, non quella che potete attivare a mano. Un avvio a freddo è l’unico test che esercita l’ordine.

Quinto passo: verificate senza la GUI

Dopo un riavvio e un accesso, verificate tre cose senza aprire la GUI. L’adattatore deve tenere un indirizzo,la tabella delle rotte deve mostrare il prefisso del sito con il gateway del tunnel come salto successivo, e un ping verso un indirizzo dall’altra parte deve rispondere. Ogni verifica corrisponde a un meccanismo diverso dei passi precedenti.

Quando l’adattatore non compare mai, il sospetto è il driver e non il profilo. Quei due guasti nel registro non si somigliano affatto, e solo uno dei due risponde a una reinstallazione del software.