VPN instalada en Windows e Linux arrinca sen rede: que comprobar

Instala unha VPN en Windows, reinicia en Linux e a conexión por cable está morta. A historia obvia escríbese soa: a VPN deixou algo atrás. A historia é falsa, porque os dous arrinques executan núcleos separados con controladores separados, táboas de encamiñamento separadas e resolutores separados. Un filtro de rede de Windows non se executa dentro de Linux, así que o fallo está na pila de Linux ou en algo que ambos os arrinques comparten de verdade, como o hardware, o firmware ou o enrutador.

O síntoma e a conclusión equivocada

A parte útil da observación é o momento: o fallo apareceu despois dun cambio. A parte inútil é o salto causal á VPN de Windows, que non pode executarse no outro sistema operativo. Separar as dúas cousas é todo o traballo. Anote a cronoloxía antes de tocar un cable.

O que si comparten os dous arrinques é o adaptador físico, o cable, o porto do conmutador e todo o que está augas arriba. Son variables compartidas reais e merecen unha comprobación despois de inspeccionar a pila de Linux.

Capture a pila de Linux con catro ordes

Comece en modo de só lectura e capture o estado antes de cambiar nada: ip -br link para a presenza de interfaces, ip -br address para os enderezos, ip route para as rutas IPv4 e ip -6 route onde IPv6 importe. A referencia da ferramenta ip distingue estes obxectos, e unha interface que aparece na lista non demostra que teña un enderezo operativo nin unha ruta utilizábel.

Garde a saída nun ficheiro para comparala máis tarde cun arrinque que funcione. Unha captura que non pode reproducir só é un recordo dun estado.

É ligazón, enderezo, ruta ou nome?

Catro fallos distintos parecen iguais desde o navegador. O dispositivo pode faltar por completo, estar presente sen portadora, estar ligado pero sen o enderezo esperado, ou ter enderezo sen ruta ata o destino. O fallo da resolución de nomes mentres os enderezos crus funcionan é un quinto caso, e pertence ao resolutor e non ao controlador.

Cada caso apunta a un traballo distinto: controlador ou firmware para un dispositivo ausente, cableado ou conmutador cando non hai portadora, DHCP ou configuración estática para un enderezo ausente, e encamiñamento ou política para unha ruta ausente. Un problema de resolutor apunta a systemd-resolved, NetworkManager ou unha configuración DNS local.

Comprobe se a instalación de Linux ten a súa propia VPN ou unha configuración de devasas persistente. Un túnel local ou un conxunto de regras nftables é un responsable do lado de Linux, e é moito máis probable que explique o fallo ca un programa de Windows que non se executa.

Despois compare a transición de arrinque

Windows Fast Startup é un apagado híbrido que conserva o estado da sesión do núcleo en lugar de realizar un arrinque completo. A documentación de Microsoft sobre estados de enerxía distíngueo dun reinicio e dun apagado completo, e por iso o mesmo hardware pode comportarse de xeito distinto nas dúas transicións.

Se o fallo depende de pasar dun sistema operativo ao outro, compare un reinicio documentado ou un apagado completo co camiño normal, despois de gardar o traballo. Un resultado que segue a transición xustifica examinar o estado do controlador, do dispositivo ou do firmware, e non demostra por si só que Fast Startup causase un fallo concreto do adaptador.

Anote que sistema operativo usou o adaptador por última vez, o tipo de transición, o estado da ligazón en Linux e a primeira operación que fallou. Unha diferenza reproducible entre arrinque en frío e transición tépeda vale moito máis ca desinstalar o software VPN das dúas instalacións sen saber que pila se rompeu.

Que non cambiar

Non reinicie as dúas pilas de rede como primeiro movemento. Iso destrúe a comparación e a miúdo non arranxa nada, porque o responsable real nunca se identificou. Non reinstale a VPN de Windows para reparar Linux, e non cambie axustes do firmware ao azar porque unha transición de arrinque se correlacionase cun fallo.

A referencia da ferramenta ip documenta os obxectos de ligazón, enderezo e ruta usados arriba. Lea primeiro o lado de Linux, conserve a captura e só despois decida se a capa de hardware compartida merece unha investigación.