VPN installata su Windows, Linux si avvia senza rete: cosa controllare

Installate una VPN su Windows, riavviate in Linux e il collegamento cablato è morto. La storia ovvia si scrive da sola: la VPN ha lasciato qualcosa dietro di sé. La storia è sbagliata, perché i due avvii eseguono kernel separati con driver separati, tabelle di routing separate e resolver separati. Un filtro di rete di Windows non viene eseguito dentro Linux, quindi il guasto è nella pila Linux oppure in qualcosa che i due avvii condividono davvero, come l’hardware, il firmware o il router.

Il sintomo e la conclusione sbagliata

La parte utile dell’osservazione è il momento: il guasto è comparso dopo un cambiamento. La parte inutile è il salto causale alla VPN di Windows, che non può girare nell’altro sistema operativo. Separare le due cose è tutto il lavoro. Annotate la cronologia prima di toccare un cavo.

Ciò che i due avvii condividono davvero è l’adattatore fisico, il cavo, la porta dello switch e tutto ciò che sta a monte. Sono variabili condivise reali e meritano un controllo dopo aver ispezionato la pila Linux.

Rilevate la pila Linux con quattro comandi

Iniziate in sola lettura e registrate lo stato prima di cambiare qualsiasi cosa: ip -br link per la presenza delle interfacce, ip -br address per gli indirizzi, ip route per le rotte IPv4 e ip -6 route dove IPv6 conta. Il riferimento dello strumento ip distingue questi oggetti, e un’interfaccia presente nell’elenco non dimostra che abbia un indirizzo funzionante o una rotta utilizzabile.

Salvate l’output in un file per confrontarlo più tardi con un avvio funzionante. Un’istantanea che non potete riprodurre è solo il ricordo di uno stato.

È il collegamento, l’indirizzo, la rotta o il nome?

Quattro guasti diversi sembrano uguali dal browser. Il dispositivo può mancare del tutto, essere presente senza portante, essere collegato ma senza l’indirizzo atteso, oppure avere un indirizzo senza rotta verso la destinazione. Il fallimento della risoluzione dei nomi mentre gli indirizzi grezzi funzionano è un quinto caso, e appartiene al resolver e non al driver.

Ogni caso rimanda a un lavoro diverso: driver o firmware per un dispositivo assente, cablaggio o switch quando manca la portante, DHCP o configurazione statica per un indirizzo assente, e routing o policy per un percorso assente. Un problema del resolver rimanda a systemd-resolved, NetworkManager o a una configurazione DNS locale.

Verificate se l’installazione Linux ha una propria VPN o una configurazione del firewall persistente. Un tunnel locale o un insieme di regole nftables è un responsabile lato Linux, ed è molto più probabile che spieghi il guasto di un programma Windows che non è in esecuzione.

Poi confrontate la transizione di avvio

Windows Fast Startup è un arresto ibrido che conserva lo stato della sessione del kernel invece di eseguire un avvio completo. La documentazione Microsoft sugli stati di alimentazione lo distingue da un riavvio e da un arresto completo, per questo lo stesso hardware può comportarsi diversamente nelle due transizioni.

Se il guasto dipende dal passaggio da un sistema operativo all’altro, confrontate un riavvio documentato o un arresto completo con il percorso normale, dopo aver salvato il lavoro. Un risultato che segue la transizione giustifica l’esame dello stato di driver, dispositivo o firmware, e non dimostra da solo che Fast Startup abbia causato un particolare guasto dell’adattatore.

Annotate quale sistema operativo ha usato l’adattatore per ultimo, il tipo di transizione, lo stato del collegamento su Linux e la prima operazione fallita. Una differenza riproducibile tra avvio a freddo e transizione a caldo vale molto più della rimozione del software VPN da entrambe le installazioni senza sapere quale pila si è rotta.

Cosa non cambiare

Non reimpostate le due pile di rete come prima mossa. Questo distrugge il confronto e spesso non risolve nulla, perché il vero responsabile non è mai stato identificato. Non reinstallate la VPN di Windows per riparare Linux, e non cambiate le impostazioni del firmware a caso perché una transizione di avvio si è correlata a un guasto.

Il riferimento dello strumento ip documenta gli oggetti collegamento, indirizzo e rotta usati sopra. Leggete prima il lato Linux, conservate l’istantanea e solo dopo decidete se lo strato hardware condiviso merita un’indagine.