La VPN y la LAN de casa comparten subred: recorred primero la ruta
Ambos adaptadores reclaman 192.168.1.0/24 y solo una ruta gana. Recorred la lista de adaptadores, la ruta ganadora y la vuelta antes de renumerar o culpar al DNS.
Te conectas a la VPN de la oficina, el icono de la bandeja se pone verde, la intranet carga y la impresora que está a dos metros deja de responder. El recurso compartido que funcionaba esta mañana da tiempo de espera agotado en la misma máquina, y ningún registro menciona una impresora. El reflejo es el DNS, porque un nombre que no se resuelve parece un nombre que no existe, pero el problema es la dirección: dos adaptadores reclaman ahora 192.168.1.0/24 y solo una ruta puede ganar ese prefijo. Recórrelo en este orden y verás qué adaptador se la quedó antes de cambiar nada.
Empieza por el síntoma, no por el túnel
La pista es el alcance. Si la intranet funciona y falla cada dispositivo local, el túnel está sano y la ruta local no. Si los dispositivos locales funcionan y falla la intranet, al contrario. Si todo funciona menos un equipo, estás ante una única dirección que existe en ambos lados.
Apunta una dirección local y una remota antes de tocar ningún ajuste. “La impresora” no es comprobable; 192.168.1.40 sí. Ese solo paso evita la hora perdida más habitual con este problema, que es reescribir los ajustes de DNS por una decisión de enrutamiento.
Paso 1: ve los dos adaptadores reclamando el prefijo
Abre Conexiones de red (ncpa.cpl) y lee los dos adaptadores uno junto al otro. El adaptador Ethernet muestra 192.168.1.50/24 con puerta de enlace 192.168.1.1. El adaptador VPN muestra 192.168.1.201/24, empujado por el servidor. Ambos son legítimos, ambos creen que el prefijo es on-link, y la pila mantendrá una sola ruta para él.
Get-NetIPAddress -AddressFamily IPv4 enumera las direcciones, y Get-NetIPInterface | Sort-Object InterfaceMetric muestra el orden en que la pila las usará. Esa columna de métrica es la decisión que estás a punto de leer, así que anota los números en lugar de recordarlos.
Demuestra barato que la teoría del DNS es falsa: Resolve-DnsName printer.office.lan devuelve la misma dirección que ayer. El nombre se resolvió; después el paquete salió por el adaptador equivocado. Dos minutos aquí ahorran una tarde en los ajustes del resolutor.
Paso 2: lee la ruta que realmente ganó
Find-NetRoute -RemoteIPAddress 192.168.1.40 imprime la interfaz, el siguiente salto y el origen que la pila usaría para esa dirección. Trata esa salida como la respuesta, no como una pista. route print -4 da toda la tabla cuando quieres ver qué entrada perdió y por cuánto.
La especificidad gana a la intención. Un 192.168.0.0/25 empujado derrota a un 192.168.0.0/24 local porque el prefijo es más largo, así que de 192.168.0.0 a 192.168.0.127 salen por el túnel mientras la mitad superior se queda local. Que media LAN desaparezca sin mensaje de error es el comportamiento correcto de esa tabla.
tracert -d 192.168.1.40 lo confirma desde fuera de la tabla: si el primer salto es una dirección de túnel en vez de tu propio router, la ruta es toda la historia. En Linux la misma pregunta es ip route get 192.168.1.40, que imprime dirección de origen y dispositivo en una línea. Cuando la respuesta nombra tun0, deja de mirar el navegador.
Paso 3: comprueba la vuelta antes de culpar al cliente
Una ruta de ida correcta falla igual si el lado lejano no puede responder. Cuando se llega a una LAN de cliente por el túnel, la puerta de enlace de esa LAN tiene que saber dónde vive el grupo del túnel: ip route add 10.8.0.0/24 via 192.168.1.12 en ese router, y push “route 192.168.1.0 255.255.255.0” desde el servidor para que los clientes conozcan la vuelta.
Sin la primera entrada, la respuesta sale del destino hacia su puerta de enlace por defecto, que reenvía una dirección privada al proveedor y la descarta. El síntoma es unidireccional y fácil de malinterpretar: las peticiones aparecen en tun0, las respuestas nunca.
Una regla masquerade en el host VPN elimina la necesidad de esa ruta estática: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. También oculta las direcciones de origen reales, lo que hace más difícil cada pregunta posterior sobre registros. Un host de destino con la puerta de enlace por defecto equivocada produce el mismo silencio, con una redirección ICMP como mejor caso y un agujero negro como habitual, y por eso la captura corresponde a ambos extremos.
Paso 4: elige una reparación con la que puedas vivir
Para esto se usan cinco reparaciones y no son intercambiables. Elige por lo que debe seguir siendo alcanzable a la vez, no por qué comando es más corto.
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
Las métricas son la opción barata y la primera a la que la gente recurre. El cambio se aplica a la interfaz, así que funciona mientras el túnel está levantado, y corresponde a un script junto al cliente, no a un shell que olvidarás. No puede dar acceso simultáneo a la misma dirección en dos redes, y ese es el límite que manda a todos los demás al resto de la tabla.
Renumerar la LAN de casa a 10.10.0.0/24 es la solución limpia: una renovación de la concesión DHCP más las reservas, las colas de impresión y las direcciones codificadas que mencionan el rango antiguo. Renumerar el lado de la oficina normalmente no es tu decisión. IPv6 elimina la colisión del todo cuando ambas redes lo llevan, usando un prefijo local único de fd00::/8 en lugar de algo memorable, pero prueba la aplicación por TCP, no con un ping, porque ICMP puede funcionar mientras el servicio no.
La propia opción de traducción de OpenVPN es el último recurso, empujada desde el servidor a una entrada de directorio específica del cliente. Toma cuatro parámetros tras el nombre de la opción — dirección, red, máscara y alias — y el alias no es opcional: push "route 192.168.2.0 255.255.255.0" y push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". La red y la máscara son el rango que el cliente ve (192.168.2.0/24), el alias es el rango real de la oficina en el lado del servidor (192.168.1.0/24), y la ruta empujada es lo que hace alcanzable ese rango visible. La oficina aparece entonces para ese cliente bajo 192.168.2.x. Documenta el mapeo en el perfil, o la siguiente persona lo depurará como una falla de enrutamiento.
Publicar un solo servicio es la versión estrecha de la traducción y no necesita en absoluto la opción de OpenVPN. Una regla DNAT en el host VPN republica un solo puerto, así que la LAN conserva sus direcciones y llega al servicio en la dirección de host que ya conoce. El coste es el habitual: el servicio ve el host VPN como origen, así que los registros por cliente y las búsquedas inversas dejan de significar nada. Eso cubre una cola de impresión o una página de administración, no hosts de ambos lados que se alcancen entre sí.
Qué seguirá sin funcionar y qué anotar
El broadcast no cruza un túnel enrutado. DLNA, UPnP, la exploración NetBIOS y Wake-on-LAN dependen de broadcast o multicast que un dispositivo tun no transporta, así que ninguna ruta arregla el descubrimiento. El puente con dev tap extiende el segmento, y con él los broadcast de DHCP, ARP y cualquier otro paquete de descubrimiento; prefiere una ruta de host unicast como route 192.168.2.1 255.255.255.255 para la dirección del lado LAN de un router remoto.
Dos routers que usan ambos 192.168.1.1 en el mismo camino pertenecen a la misma familia de problemas: la dirección local siempre gana, así que la página del router lejano sigue inalcanzable hasta que una LAN se mueve. Añadir un segundo adaptador no cambia nada en ninguno de los dos casos.
Anota las pruebas antes de editar nada: ip route get o Find-NetRoute, ping -c 3 a la dirección en cuestión, un traceroute, y tcpdump -ni tun0 icmp en el cliente, después la tabla de enrutamiento y los contadores NAT en el servidor. Un ping que funciona en un sentido y muere en el otro apunta a la vuelta, no al túnel, y esa sola distinción decide cuál de las reparaciones de arriba necesitas de verdad.