El Wi-Fi funciona con la VPN del router. ¿Y los puertos por cable?
Una prueba correcta de Wi-Fi no demuestra que un puerto por cable use la misma política. Compare la puerta de enlace, la VLAN y el DNS en el propio dispositivo cableado.
El portátil por Wi-Fi muestra la dirección de salida de la VPN, y el equipo de escritorio cableado de la habitación contigua muestra la del proveedor. Ambos están conectados al mismo router, así que la diferencia no está en la configuración de la VPN. Está en qué interfaz, VLAN o política atravesó realmente el tráfico. La cobertura es una propiedad de cada ruta, no una propiedad del equipo.
Comparar los dos clientes uno al lado del otro encuentra la diferencia más rápido que leer las reglas del router.
Dos caminos hacia el mismo router
Un router con cliente VPN puede dirigir el tráfico de un puente, una VLAN o una lista de puertos y dejar el resto en la WAN. Es un diseño normal, y por eso una prueba Wi-Fi correcta solo demuestra la ruta Wi-Fi. Un conmutador gestionado también puede poner un puerto de pared en un segmento distinto del que usa el punto de acceso, sin que nadie toque el router. Las políticas basadas en puertos son las más fáciles de pasar por alto, porque el puerto parece parte de la misma LAN.
El mismo hardware, otra política. La caja física no es la frontera que usted cree.
Compare la puerta de enlace que usa cada cliente
En el dispositivo cableado, lea la interfaz activa, su dirección y su puerta de enlace predeterminada. En una máquina con Wi-Fi y Ethernet activos, la métrica de enrutamiento decide cuál gana, y a menudo no es la que espera. Compare esa puerta de enlace con la que usó el cliente inalámbrico, y compruebe a qué red del router pertenece el puerto del conmutador. La receta de cliente WireGuard de pfSense muestra cómo un solo router puede tener un túnel y dejar tranquilas las demás interfaces.
Si las dos puertas de enlace difieren, ya tiene la respuesta antes de tocar una sola regla de firewall.
Compare DNS e IPv6 por separado
Un cliente cableado con un resolutor configurado a mano puede saltarse por completo la política DNS del router, incluso cuando su tráfico se dirige correctamente. IPv6 es la otra mitad: un túnel que solo maneja IPv4 puede dejar el tráfico IPv6 por la ruta nativa. Pruebe una consulta de nombre y un destino IPv6 desde el dispositivo cableado, no solo una comprobación de dirección IPv4. Use una consulta que solo el resolutor del router podría responder, como un nombre de host interno.
Cada una de esas es una comparación aparte, y cada una puede fallar por su cuenta.
Compare qué ocurre cuando el túnel se cae
Si el diseño exige acceso solo por VPN, detenga el túnel y pruebe el cliente cableado con tráfico inofensivo. Un dispositivo cableado que vuelve a la WAN normal sigue en línea pero pierde la ruta prevista, lo que a quien solo comprueba la conectividad le parece un éxito. El cliente inalámbrico puede comportarse distinto, y esa diferencia es la comparación que vale la pena.
El comportamiento ante fallos forma parte de la cobertura, no es un caso límite posterior.
Atribuya el resultado a la capa correcta
Un cliente VPN a nivel de dispositivo o un proxy del navegador en la máquina cableada pueden cambiar la dirección de salida medida al margen del router. Anote qué capas estaban activas durante la prueba, o un cambio de dirección correcto se atribuirá a la puerta de enlace equivocada. La misma precaución vale para un resultado en caché anterior al cambio.
Pruebe tráfico nuevo, anote las capas y escriba el segmento y la interfaz. Ese registro es lo que hace que la próxima comparación tenga sentido en lugar de ser otra suposición.