El adaptador virtual de SoftEther aparece pero no envía tráfico

Un adaptador virtual de SoftEther aparece en la lista de redes del sistema operativo, se declara desconectado y no transporta ningún tráfico. Esa combinación es normal en un dispositivo sin una sesión asociada, y también es el estado que ve cuando hay un perfil incorrecto vinculado a él. El adaptador es un dispositivo que posee el sistema operativo; la sesión es lo que le da vida. Recorra estas cuatro comprobaciones en orden y deténgase en la primera que falle.

Separe el dispositivo de la sesión

Crear el adaptador instala un dispositivo de red; no se autentica con ningún servidor. Confirme qué dice la lista de conexiones del cliente antes de sacar conclusiones del estado de la interfaz. Un perfil que no está conectado explica el estado desconectado sin más investigación.

El adaptador y la interfaz física tienen trabajos distintos. Uno transporta el tráfico descifrado que ven las aplicaciones, y el otro transporta la conexión exterior cifrada hacia el servidor. Confundir ambos hace que las reglas del cortafuegos y las rutas se apliquen al dispositivo equivocado. Las reglas escritas para la interfaz física no coincidirán con el tráfico del túnel, y las reglas escritas para el túnel no afectarán a la conexión exterior.

Empareje un adaptador con un perfil

Cada adaptador debe estar vinculado al perfil de conexión que se propone, y el vínculo debe ser visible en el cliente en lugar de recordarse. Cuando existen varios adaptadores, anote qué perfil posee qué dispositivo antes de tocar cualquiera de ellos. Reutilizar un adaptador entre perfiles es como una dirección obsoleta sobrevive a una reconexión.

Si el cliente ofrece una forma compatible de recrear el vínculo, úsela en lugar de editar directamente la configuración del sistema operativo. El cliente escribe la configuración del adaptador al conectar, así que los cambios manuales suelen desaparecer o entrar en conflicto en la sesión siguiente.

Lea la configuración efectiva tras conectar

Una vez establecida la sesión, lea la dirección, la ruta y el resolutor del sistema. El panel de estado del cliente describe lo que pidió, mientras que el núcleo describe lo que ocurrió realmente.

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

El listado de direcciones muestra si el adaptador recibió algo, y un adaptador sin dirección tras un inicio de sesión correcto apunta a la configuración del perfil y no al controlador. La consulta de ruta muestra qué interfaz transportaría un destino privado, y ahí es donde una ruta ausente se vuelve visible. La salida del resolutor muestra si DNS siguió a la sesión, ya que un enlace funcional con DNS local sigue produciendo una conexión medio rota.

Un adaptador creado sin ajustes útiles puede coexistir con un inicio de sesión de gestión correcto en otra parte del cliente. Los dos paneles responden preguntas distintas, así que uno nunca es prueba del otro. Cuando no coinciden, la vista del sistema es la que experimentan las aplicaciones.

Deténgase antes de puentear o borrar

Puentear el adaptador virtual con uno físico es un cambio de diseño, no una reparación. Fusiona dos fronteras de red y no es una forma de arreglar una ruta ausente. Si el despliegue necesita esa disposición, necesita un diseño autorizado y un plan de pruebas.

Borrar un adaptador es igual de destructivo cuando otro servicio lo usa. Identifique primero al propietario, incluido cualquier otro cliente o producto de virtualización de la máquina que haya creado una interfaz con un nombre similar. Un dispositivo que reaparece tras retirarlo le dice que algo lo está recreando.

Termine probando la aplicación, no el adaptador. Un recurso compartido o una página de intranet que carga por el túnel es la prueba de que el dispositivo, la sesión y la ruta están de acuerdo.