Guía de puertos FRP: túneles de proxy inverso en el puerto 7000

FRP tiene un lado del servidor llamado frps y un lado del cliente llamado frpc. frps se ejecuta en una máquina con una dirección pública accesible. frpc se ejecuta cerca del servicio privado, se conecta hacia afuera a frps, se autentica y solicita a frps que exponga un servicio local a través de un proxy configurado.

Este modelo es útil cuando un laboratorio doméstico, una sucursal, un dispositivo, un entorno de prueba o un servicio de red privada necesitan acceso externo temporal o controlado. También significa que frps se convierte en un borde de Internet, por lo que los tokens, TLS, ACL, registros y el alcance del servicio son tan importantes como el puerto mismo.

TCP 7000 se usa comúnmente como frps bind_port, donde frpc establece la conexión de control. El modo de proxy inverso HTTP y HTTPS puede utilizar vhost_http_port y vhost_https_port, a menudo 80 y 443. Las asignaciones de proxy TCP y UDP pueden exponer puertos remotos personalizados a los que los usuarios se conectan directamente.

FRP también puede exponer un panel, un punto final de métricas o una interfaz de administración según la configuración. Esos puertos de gestión no deben tratarse como puertos de aplicaciones públicas. Restrinjalos a IP confiables, VPN, host local o redes privadas.

Abra el puerto de enlace frps cuando los clientes frpc confiables necesiten registrar túneles desde redes privadas. Abra puertos remotos orientados al usuario solo para los servicios que publica intencionalmente, como una vista previa de una aplicación web, acceso SSH a través de un túnel controlado, un receptor de webhook o un servidor de juegos.

No exponga amplios rangos de puertos o interfaces de administración solo porque FRP lo hace fácil. Cada puerto remoto es un punto de entrada público a algo detrás del túnel, y cada mapeo debe tener un propietario, propósito, política de acceso y fecha de eliminación si es temporal.

Antes de permitir el puerto 7000, decida qué clientes pueden conectarse, qué tipos de proxy están permitidos, qué puertos remotos pueden registrarse y si el tráfico debe usar TLS. Revise los tokens de autenticación o la configuración de OIDC, los nombres de los clientes y si es posible escalar privilegios a través de puertos remotos arbitrarios.

Un verificador de puertos puede confirmar si se puede acceder al puerto de enlace FRP o a un puerto remoto publicado, pero no puede probar que la autenticación FRP, la propiedad de la ruta o la seguridad del servicio backend sean correctas. Valide tanto la ruta de control del túnel como el comportamiento de la aplicación expuesta.

En un servidor en la nube, ejecute frps con una IP pública fija o un nombre DNS estable, permita solo el puerto de enlace requerido y los puertos de servicio publicados, y mantenga privado el acceso al panel o al administrador. Coloque el tráfico HTTP y HTTPS detrás de TLS normal y del enrutamiento basado en host siempre que sea posible.

En clientes Linux o Windows, ejecute frpc como un servicio cerca de la aplicación privada. Configure local_ip, local_port, tipo de proxy, puerto_remoto o dominio personalizado y las credenciales con cuidado. Evite reutilizar el mismo token en entornos no relacionados.

Si se utiliza FRP para acceso similar a producción, agregue supervisión de procesos, retención de registros, monitoreo, renovación de certificados y control de cambios. Un túnel que comienza como una conveniencia puede convertirse en infraestructura crítica más rápido de lo esperado.

Comience con una verificación del puerto externo con el nombre de host público de frps o IP y el puerto 7000. Si está abierto, los clientes de frpc pueden comunicarse con el oyente de control. Luego verifique los registros de frps y frpc para confirmar la autenticación, el registro del proxy y el estado de los latidos.

A continuación, pruebe el servicio publicado. Para túneles HTTP o HTTPS, utilice curl o un navegador en el dominio público. Para túneles TCP, conéctese al puerto remoto configurado con el cliente real. Un puerto de control en buen estado no garantiza que la aplicación backend o la asignación de puertos remotos estén funcionando.

Si el puerto 7000 está cerrado, es posible que frps no se esté ejecutando, que esté vinculado al host local o que esté bloqueado por el firewall del host o el grupo de seguridad de la nube. Si frpc no puede conectarse, verifique también DNS, server_addr, bind_port, configuración de TLS, discrepancia de token y reglas de salida de red en el lado del cliente.

Si la conexión de control funciona pero no se puede acceder al servicio, inspeccione los conflictos de puerto_remoto, el enrutamiento del dominio vhost, los encabezados del host HTTP, los escuchas de servicios locales, NAT en el lado frpc y la política de frps enable_ports. Muchos problemas de FRP ocurren después de que se registra el túnel, no en la verificación inicial del puerto.

Trate frps como una puerta de enlace pública. Utilice una autenticación sólida, rote tokens, restrinja los puertos permitidos, deshabilite los tipos de proxy no utilizados, proteja los paneles y registre las conexiones de los clientes y los registros de proxy. No exponga herramientas de administración interna a través de FRP sin una capa de autenticación adicional.

Para servicios confidenciales, coloque FRP detrás de una VPN, un proxy con reconocimiento de identidad, mTLS, una lista permitida de firewall o un proxy inverso con limitación de velocidad. Revise los túneles activos con regularidad y elimine las asignaciones que ya no tengan un propietario o propósito comercial claro.