Client SoftEther all’avvio: AccountStartupSet e l’ordine del demone

Riavviare la macchina la lascia sulla rete con il tunnel di nuovo down. Il client di SoftEther conserva due stati che la maggior parte delle persone tratta come uno solo: se il servizio è in esecuzione e se a un account salvato è consentito salire con esso. Entrambi devono essere veri, e il secondo è un flag per account, non un’impostazione di avvio. Eseguite i quattro controlli sotto in ordine e fermatevi al primo errore.

Confermate che l’account è contrassegnato per l’avvio automatico

Il flag vive nel record dell’account dentro la configurazione del client stesso, quindi reinstallare il client o ripristinare una directory vuota lo cancella. Aprite la console di gestione e guardate l’elenco degli account prima di cambiare qualsiasi altra cosa.

cd /opt/softether/vpnclient
./vpncmd

Scegliete 2 per la gestione del client VPN e accettate il server locale premendo Enter.

AccountStartupSet
office-hub
exit

AccountStartupSet registra l’account come uno da far salire all’avvio del servizio client. Non avvia il servizio né crea un nuovo account, e non stampa nulla di utile quando il nome è sbagliato. Rileggete l’elenco degli account dopo il comando, perché un errore di battitura è silenzioso e sembra esattamente un flag che non ha avuto effetto.

Confermate che il servizio parte, e abbastanza presto

Su Linux il client gira come demone dalla propria directory, e deve essere attivo prima che qualsiasi passo di avvio tenti di usare l’account. Un breve hook che cambia directory e lo avvia basta sui sistemi che eseguono ancora rc.local.

cd /opt/softether/vpnclient
./vpnclient start

Dove rc.local non c’è più, scrivete un’unità systemd con WorkingDirectory esplicito e una politica di riavvio. Il binario risolve la sua configurazione rispetto al punto da cui viene avviato, quindi un’unità senza quell’impostazione può partire con successo e non leggere nulla. L’ordine è la seconda metà del problema: un tentativo di connessione che gira prima che il demone ascolti fallisce a intermittenza, cosa molto più difficile da diagnosticare di un fallimento costante. Una politica di riavvio copre il terzo caso, quando il demone muore silenziosamente ore dopo.

Controllate l’elenco dei processi invece di fidarvi di un file pid lasciato dall’avvio precedente.

Confermate che l’adattatore ha ricevuto un indirizzo

Quando l’account si connette, il client presenta un adattatore virtuale e l’adattatore ha ancora bisogno di un indirizzo. Un hub con SecureNAT di solito risponde al DHCP; un hub in bridge su una LAN fisica si aspetta invece che risponda il server di quella LAN.

ip -brief address
dhclient vpn_vpn1

Prendete il nome dell’interfaccia dall’elenco, perché il numero in un esempio non è una costante. Se l’indirizzo deve essere statico, mettetelo nella configurazione di rete della distribuzione per quell’interfaccia, così viene riapplicato dopo un evento di link e non solo all’avvio. Uno script una tantum lascia l’adattatore senza indirizzo la prima volta che il tunnel si riconnette durante la giornata. Quel guasto sembra un tunnel morto anche se l’account è a posto.

Un adattatore senza indirizzo è il guasto più silenzioso dell’elenco, dato che l’account riporta comunque di essere connesso.

Confermate che la route punta dove pensate

Il traffico può comunque fallire con un link sano e un indirizzo valido. Chiedete al kernel quale interfaccia userebbe per una destinazione nella sottorete dell’hub, poi confrontate quella risposta con il tunnel.

ip route get 10.10.20.15

Una sottorete locale che si sovrappone all’intervallo dell’hub vince, perché la sua route è più specifica e già installata.

È una decisione di numerazione, non un bug del client, e riavviare il servizio non la cambierà. La configurazione del resolver è l’altra metà: un indirizzo senza un server DNS funzionante produce un tunnel che supera ogni controllo del link e comunque non riesce ad aprire un nome.

Scrivete i quattro controlli nelle note di ricostruzione

Annotate insieme il nome dell’account, il comando di avvio del servizio e il nome dell’interfaccia, perché un host ricostruito ripristina i dati dell’account ma non l’hook del sistema operativo che lancia il demone. Quelli vivono in posti diversi e di solito vengono salvati da persone diverse.

Il flag è una riga da riapplicare e facile da dimenticare.

Mantenete l’ordine: flag, servizio, indirizzo, route. Una checklist che parte dal mezzo produce molte risposte sbagliate e sicure di sé.