L’adattatore virtuale SoftEther compare ma non invia traffico

Un adattatore virtuale SoftEther compare nell’elenco di rete del sistema operativo, si dichiara scollegato e non trasporta alcun traffico. Questa combinazione è normale per un dispositivo senza una sessione collegata, ed è anche lo stato che si vede quando vi è associato il profilo sbagliato. L’adattatore è un dispositivo di proprietà del sistema operativo; la sessione è ciò che gli dà vita. Seguite questi quattro controlli in ordine e fermatevi al primo che fallisce.

Separate il dispositivo dalla sessione

Creare l’adattatore installa un dispositivo di rete; non si autentica con alcun server. Verificate cosa dice l’elenco delle connessioni del client prima di trarre conclusioni dallo stato dell’interfaccia. Un profilo non connesso spiega lo stato scollegato senza ulteriori indagini.

L’adattatore e l’interfaccia fisica hanno compiti diversi. Uno trasporta il traffico decifrato che le applicazioni vedono, e l’altro trasporta la connessione esterna cifrata verso il server. Confondere i due porta ad applicare regole del firewall e rotte al dispositivo sbagliato. Le regole scritte per l’interfaccia fisica non corrisponderanno al traffico del tunnel, e le regole scritte per il tunnel non influiranno sulla connessione esterna.

Abbinate un adattatore a un profilo

Ogni adattatore dovrebbe essere associato al profilo di connessione che si intende usare, e l’associazione dovrebbe essere visibile nel client invece che ricordata. Quando esistono più adattatori, annotate quale profilo possiede quale dispositivo prima di toccarne uno. Riusare un adattatore tra profili diversi è il modo in cui un indirizzo obsoleto sopravvive a una riconnessione.

Se il client offre un modo supportato per ricreare l’associazione, usatelo invece di modificare direttamente la configurazione del sistema operativo. Il client scrive le impostazioni dell’adattatore alla connessione, quindi le modifiche manuali spesso scompaiono o entrano in conflitto alla sessione successiva.

Leggete le impostazioni effettive dopo la connessione

Una volta attiva una sessione, leggete l’indirizzo, la rotta e il resolver dal sistema. Il pannello di stato del client descrive ciò che ha richiesto, mentre il kernel descrive ciò che è realmente accaduto.

ip -brief address show
ip route get 10.20.30.41
resolvectl status | head -20

L’elenco degli indirizzi mostra se l’adattatore ha ricevuto qualcosa, e un adattatore senza indirizzo dopo un accesso riuscito indica la configurazione del profilo e non il driver. L’interrogazione della rotta mostra quale interfaccia trasporterebbe una destinazione privata, ed è lì che una rotta assente diventa visibile. L’output del resolver mostra se il DNS ha seguito la sessione, poiché un collegamento funzionante con DNS locale produce comunque una connessione mezzo rotta.

Un adattatore creato senza impostazioni utili può coesistere con un accesso di gestione riuscito altrove nel client. I due pannelli rispondono a domande diverse, quindi uno non è mai prova dell’altro. Quando non concordano, la vista del sistema è quella che le applicazioni sperimentano.

Fermatevi prima di fare bridge o eliminare

Collegare con un bridge l’adattatore virtuale a uno fisico è un cambio di progettazione, non una riparazione. Fonde due confini di rete e non è un modo per correggere una rotta assente. Se la distribuzione richiede questa disposizione, richiede un progetto autorizzato e un piano di test.

Eliminare un adattatore è altrettanto distruttivo quando un altro servizio lo usa. Identificate prima il proprietario, compreso qualsiasi altro client o prodotto di virtualizzazione sulla macchina che abbia creato un’interfaccia con un nome simile. Un dispositivo che riappare dopo la rimozione vi dice che qualcosa lo sta ricreando.

Concludete provando l’applicazione, non l’adattatore. Una condivisione file o una pagina intranet che si carica attraverso il tunnel è la prova che dispositivo, sessione e rotta sono d’accordo.