Un solo host público para VPN y web: cómo separar los papeles

Una sola máquina puede atender las tres necesidades a la vez: terminar túneles, responder HTTPS y reenviar entre dos LAN privadas. Si eso es sensato depende de tres cosas que puede resolver sobre el papel: quién posee la dirección pública, quién posee cada par de puerto y protocolo, y a qué proceso se le permite reenviar paquetes. Si acierta, el host compartido no tiene nada de especial. Si falla, pasará un fin de semana con un servicio que arranca limpio y nunca responde.

Lo que sigue es un procedimiento de decisión, no una hoja de construcción. Cada paso termina con la comprobación que demuestra que el papel que acaba de añadir está realmente aislado.

Elija al dueño de la dirección antes que los puertos

Un extremo de túnel y un servidor web pueden compartir un núcleo; compartir una dirección, un puerto y un protocolo al mismo tiempo es lo que falla. WireGuard suele ocupar UDP 51820, OpenVPN ocupa UDP 1194 o TCP 443, y un servidor web ocupa TCP 443. El par que duele es OpenVPN sobre TCP 443 junto a HTTPS, porque ambos quieren el mismo socket y el núcleo se lo entrega a quien se enlazó primero. Solo un demultiplexor delante, como sslh o un proxy que entienda TLS, les permite compartir ese puerto, y añade un componente cuyo fallo se parece exactamente a un problema de cortafuegos.

Mire a los dueños antes de cambiar nada: ss -lntup imprime la dirección local, el puerto y el proceso de cada socket que escucha. Dos filas con 0.0.0.0:443 significan que el segundo servicio nunca se enlazó, por muy alegre que fuera su script de inicio. El bridge también mueve al dueño. Cuando eth0 se une a br0, la IP se traslada a br0 y toda regla de cortafuegos que nombre eth0 deja de coincidir, así que enlace los servicios en el bridge y confírmelo con ip -br addr.

La misma regla de propiedad explica una sorpresa que aparece con las máquinas virtuales. Un servidor de túnel que se ejecuta dentro de un invitado en la misma LAN conserva la dirección del invitado, así que las conexiones dirigidas a la dirección propia del anfitrión se quedan en el anfitrión y el túnel del invitado nunca las ve, diga lo que diga el perfil del cliente.

Enrute entre las dos LAN o haga NAT en un lado

Dos LAN que no se ven pueden marcar cada una el host público, que luego reenvía entre los túneles. Ese diseño enrutado necesita tres cosas: reenvío activado, una ruta hacia cada prefijo remoto y una política de reenvío que deje pasar el tránsito. sysctl -w net.ipv4.ip_forward=1 cubre la primera, ip route add 10.20.0.0/24 dev wg1 la segunda, y una línea de nftables como nft add rule inet filter forward iifname "wg0" oifname "wg1" accept la tercera.

El NAT de origen es más fácil de añadir y más difícil de depurar. El enmascaramiento reescribe la dirección del cliente, así que el lado remoto ve el concentrador en lugar del anfitrión real, y sus reglas de acceso y registros dejan de ser útiles para atribuir. Cuando las dos redes son suyas, enrute. Cuando un lado pertenece a un tercero que no añadirá una ruta de vuelta, el NAT es la opción que se entrega esta semana. En cualquier caso, escriba el plan de direcciones, porque dos /24 solapadas no se pueden enrutar con ninguna cantidad de configuración.

Nada de que haga de salida a internet para un portátil impide que la misma caja termine túneles entrantes. Solo lo impiden las direcciones solapadas, y por eso el plan de direcciones es el documento que importa.

Pruebe la separación con dos papeles detenidos

La prueba útil es la resta: detenga dos papeles y confirme que el tercero sigue respondiendo. Una petición web debería completarse con el servicio de túnel caído, y un handshake de túnel debería completarse con el servidor web detenido. Si ambos solo funcionan cuando todo funciona, tiene una dependencia accidental: una tabla de cortafuegos compartida, una ruta extraviada o un nombre que apunta a la dirección equivocada.

Tres comandos hacen concreta esa prueba. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ demuestra que el oyente local responde sin DNS externo, wg show en el cliente demuestra que el handshake se completó, y tcpdump -ni any port 51820 en el concentrador separa un problema de enrutamiento de un problema de clave. Un handshake que nunca aparece en la captura murió antes del anfitrión: cortafuegos del proveedor, dirección pública equivocada o una regla de NAT en el camino.

Repita la resta para las LAN reenviadas. Con un par desconectado, un ping a través del concentrador debería fallar; con él reconectado, el ping debería recuperarse sin tocar ninguna regla. Un ping que solo se recupera tras reiniciar el túnel apunta a la política y no al alcance, y esa es otra corrección.

Mantenga legible el conjunto de reglas mientras resta papeles. nft list ruleset debería mostrar una regla de aceptación por dirección que realmente necesite, y una cadena forward que lo acepta todo no es separación, es una demo que funciona.

Líneas de acceso solo IPv6 y servicios IPv4

Algunas líneas de acceso solo dan alcance IPv6, y los servicios aún deben publicarse sobre IPv4. El túnel viaja por la familia que aún pasa tráfico, mientras que el servicio publicado se sienta en una dirección dentro del túnel. Eso invierte la suposición habitual y rompe el monitoreo en silencio: una regla de cortafuegos o una comprobación de disponibilidad escrita para la ruta IPv4 ahora vigila una interfaz que no lleva nada.

Pruebe cada familia por separado con curl -4 y curl -6, porque una petición correcta no dice nada sobre la ruta que no probó. La propiedad del puerto no cambia entre familias, pero el oyente sí: ss -lntup lista los sockets IPv4 e IPv6 como filas separadas, y 0.0.0.0:443 no cubre [::]:443 salvo que el proceso haya pedido un socket de doble pila.

Un servicio que responde en una familia y rechaza en la otra suele ser un problema de oyente, no de enrutamiento. Antes de dar el diseño por terminado, confirme que cada papel posee su propia dirección o puerto, que el reenvío está activado y permitido, y que cada papel sigue respondiendo con los otros dos detenidos.