La configuración de VPN del Mac no inicia un servidor: dónde vive la puerta de enlace

Dos tareas distintas llevan el nombre de VPN en macOS, y el panel de ajustes solo se ocupa de una. Si quieres que el tráfico de este Mac salga por un proveedor o una puerta de enlace remota, una entrada de cliente es todo lo que necesitas. Si quieres llegar a la impresora, al NAS o a una página de administración de tu red doméstica desde una habitación de hotel, entonces algo de esa red tiene que aceptar conexiones desde fuera, y un Mac actual no es esa pieza recién salido de la caja. Tres preguntas determinan en qué caso estás, y merece la pena responderlas antes de escribir una dirección en un campo.

Una entrada de cliente nombra un destino, no un oyente

En Ajustes del Sistema > Red > VPN en macOS Ventura y posteriores, los campos que las versiones antiguas guardan en Preferencias de Red describen cómo llegar al extremo de otra persona: una dirección de servidor, un ID remoto, una cuenta o certificado y reglas opcionales de conexión a demanda. Guardar esa entrada almacena una conexión en la configuración de red de tu Mac. Nada en el proceso vincula un puerto, abre un oyente ni inscribe a un usuario remoto.

Puedes comprobarlo desde el intérprete de comandos. En un Mac que sospechas que sirve, ejecuta sudo lsof -nP -iUDP y busca los puertos que usa tu protocolo: 500 y 4500 para IKEv2, 1194 para el valor predeterminado de OpenVPN, 51820 para WireGuard. Una máquina solo cliente muestra sockets emparejados con una dirección y un puerto remotos, no una vinculación comodín a la que pudiera llegar cualquier cosa de internet. Los túneles que corren dentro de una Network Extension pueden ocultarse de lsof, así que contrasta igualmente el panel de estado de la propia aplicación; lo que no encontrarás es una preferencia de Apple que convierta este Mac en la puerta de enlace.

Tres preguntas separan los dos papeles

Revísalas en orden. La primera suele decidir el resto, y la tercera es donde más se equivoca la planificación específica del Mac.

1. ¿Quién inicia la conversación? Si tu Mac marca hacia fuera y el otro lado responde, necesitas un cliente. Si los dispositivos de internet tienen que marcar hacia dentro para llegar a tu red, necesitas una puerta de enlace con un punto de entrada público, y el Mac puede seguir siendo cliente de esa puerta.

2. ¿Qué debe ser accesible mientras el túnel está activo? Un servicio en un host es una decisión de reenvío de puerto. Una subred entera, incluida la resolución de nombres, es una decisión de enrutamiento y DNS, y cambia lo que la puerta de enlace debe reenviar, no lo que dice la entrada de cliente.

3. ¿Qué versión del sistema operativo ejecuta el extremo que acepta? Para los Mac esa pregunta tiene una respuesta dura. Apple indica que la VPN se eliminó de macOS Server 5.7.1, y la propia aplicación macOS Server se descatalogó el 21 de abril de 2022; la página que conviene leer cuando un tutorial antiguo te lleva por una casilla de servicio VPN que ya no existe es el aviso de historial del servicio.

Cuando la primera respuesta es «alguien de fuera inicia», deja de buscar un interruptor en el panel de cliente del Mac y elige el host que terminará el túnel.

Dónde puede vivir la puerta de enlace en su lugar

Cuatro disposiciones cubren la mayoría de los casos domésticos y de oficina pequeña. Un router con un modo servidor auténtico, frente a un modo cliente con otra etiqueta, termina el túnel en el borde y mantiene bajo el número de hosts, a costa de quedar atado al soporte de protocolos de ese firmware. Un NAS o un mini PC siempre encendido ejecuta el paquete de servidor del fabricante y te deja registros que puedes leer. Una VM pequeña en la nube te da una dirección pública que controlas y llega a casa por un segundo túnel. Una red de malla construida sobre WireGuard, o un servicio gestionado que retransmite entre pares, evita el reenvío de puertos entrantes haciendo que ambos extremos marquen hacia fuera.

La frontera entre esas opciones suele ser tu conexión a internet, no el software. Si el proveedor te coloca detrás de un NAT de nivel de operador, ningún reenvío de puertos en el router produce un punto de entrada accesible, y la respuesta honesta es una disposición con relé o malla. Compara la dirección WAN que informa tu router con la dirección que ve el mundo exterior; si difieren y el valor del router cae en un rango privado o compartido, planifica el caso del relé.

Elijas el host que elijas, reenvía un protocolo en un puerto en lugar de un rango, y mantén el Mac fuera del camino de entrada salvo que ese producto concreto documente un papel de servidor para la versión de macOS que ejecutas.

Confirma el papel antes de repartir perfiles

En la puerta de enlace candidata, demuestra que existe un oyente en vez de confiar en que el instalador haya creado uno. En macOS eso significa sudo lsof -nP -iUDP filtrado a los puertos anteriores, más sudo pfctl -s nat si las reglas del filtro de paquetes forman parte del diseño. En Linux, ss -lunp muestra los mismos hechos sin ambigüedad.

Luego prueba desde fuera de la red, con el protocolo mismo. El ping demuestra poco: el ICMP suele filtrarse y no dice nada del UDP 51820. Un handshake de cliente con registro detallado, ejecutado desde un teléfono con datos móviles, es la prueba real más barata porque cruza el mismo camino que cruzará un colega remoto.

Solo después tocas los perfiles de cliente. En el Mac, scutil --nc list imprime los servicios VPN que el sistema conoce; si la puerta de enlace que acabas de construir no está entre ellos, estás configurando una máquina distinta de la que probaste. Si el handshake funciona en la LAN pero falla desde fuera, la culpa está en el camino de entrada: regla NAT, CGNAT del proveedor o cortafuegos en la puerta de enlace, en ese orden.

Antes de construir nada, resuelve cuatro puntos:

• Qué lado inicia la conexión, tu Mac o un dispositivo remoto.
• Si la versión del sistema operativo y el producto del host que acepta admiten de verdad un papel de servidor.
• Si tu proveedor te da alguna dirección pública accesible.
• Qué único puerto y protocolo aceptará la puerta de enlace, y qué servicio detrás responde.

El siguiente paso es concreto: elige el host de la puerta de enlace, confirma su oyente desde fuera y solo entonces crea la entrada de cliente en el Mac que apunta a ella.