Esa dirección L2TP es IPCP, no una concesión DHCP en la LAN

La conexión se levanta y el adaptador muestra una dirección dentro del rango de la oficina, así que la conclusión natural es que la VPN le dio una dirección de la LAN y, por tanto, le puso en la LAN. Ninguna de las dos mitades es del todo cierta. L2TP transporta una sesión PPP, y PPP negocia la dirección IPv4 interna con IPCP. Esa dirección es un parámetro de sesión acordado entre dos pares, no una concesión entregada por el servidor DHCP de la oficina, y tenerla no le convierte en vecino en el cable de la oficina.

Dos direcciones en una conexión

Hay dos negociaciones independientes en una conexión L2TP. La externa establece una ruta protegida entre su dispositivo y el punto final de la VPN sobre la red que ya tenga. La interna es la sesión PPP, y es donde se acuerdan la dirección de su sesión y la del otro extremo. El tráfico de Internet puede salir bajo una tercera dirección por completo, la pública del punto final, y por eso una página de comprobación de VPN y la dirección del adaptador rara vez coinciden.

Mantener esos tres papeles separados responde a la mayoría de las preguntas que la gente trae a esta capa. Un número privado en la interfaz VPN es normal y esperable. No dice nada sobre si el punto final cambió su salida pública, y por sí solo no decide qué destinos alcanza su tráfico.

Qué hace exactamente IPCP

IPCP es el protocolo de control de IPv4 para PPP. Cada lado envía mensajes Configure-Request que describen las opciones que quiere, y la opción de dirección es una de ellas. Un cliente que aún no tiene dirección suele preguntar con 0.0.0.0, y el servidor responde con un Configure-Nak que lleva la dirección que quiere que use el cliente. Después el cliente pide esa dirección y la sesión se levanta con una dirección local y una remota.

Ese intercambio está documentado en las especificaciones de PPP e IPCP, y explica un detalle que parece un error: la dirección la elige el servidor según su propia política, que puede ser un grupo, un ajuste por usuario o una dirección ligada a la identidad autenticada. Cuando el grupo se agota, o la política entra en conflicto con la petición, la autenticación puede tener éxito mientras la negociación de dirección falla, y el cliente informa de una conexión que nunca se estabiliza.

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

Una línea del registro de pppd que nombre una dirección local y una remota es el final correcto de esa negociación. Su ausencia, junto a una autenticación correcta, apunta a la etapa de dirección y no a las credenciales.

Por qué la LAN no puede responderle

Una dirección del rango del lado remoto crea la expectativa de que los equipos de esa LAN pueden alcanzarle, y casi nunca pueden salvo que el servidor enrute la dirección de su sesión de vuelta al túnel. Estar dentro de un grupo es una afirmación sobre la asignación, no sobre la topología. El servidor de archivos de la oficina no tiene ruta hacia la dirección de su sesión salvo que el servidor VPN la reenvíe, y puede que ni siquiera esté permitido aunque lo haga.

También por eso los rangos solapados causan problemas desproporcionados respecto a su tamaño aparente. Si el grupo se solapa con una LAN que el cliente ya usa, la tabla de rutas del cliente tiene ahora dos pretensiones sobre el mismo prefijo, y la incorrecta suele ganar por motivos que nada tienen que ver con el túnel.

Verifique la sesión y luego la ruta

Compruebe primero la interfaz, luego las rutas y luego un destino que importe. Cada paso tiene su propio modo de fallo, y probar los tres a la vez produce una conclusión que después no podrá defender.

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

Si la comprobación pública muestra la dirección del punto final mientras un destino privado agota el tiempo, el túnel lleva su ruta por defecto y el lado remoto no responde para ese destino. Si el destino privado responde pero la comprobación pública no cambia, el perfil usa túnel dividido y solo parte del tráfico utiliza la sesión.

Mantenga las tres etapas separadas

La autenticación, la negociación de dirección y el reenvío fallan de forma distinta, y cada una tiene un responsable distinto. Las credenciales son un problema de identidad, el agotamiento de IPCP es un problema de política del servidor y una ruta de retorno ausente es un problema de diseño de red. Informar de las tres como “la VPN está rota” garantiza una solución lenta.

Anote la dirección asignada, el grupo del que vino y si se supone que la LAN debe alcanzarla. Esa única nota evita que la siguiente persona suponga una concesión DHCP y busque un ámbito que nunca estuvo implicado.