frp
0.61.0
LÉAME | 中文文档
frp es un proyecto de código abierto cuyo desarrollo continuo es posible en su totalidad gracias al apoyo de nuestros increíbles patrocinadores. Si desea unirse a ellos, considere patrocinar el desarrollo de frp.
frp es un proxy inverso rápido que le permite exponer a Internet un servidor local ubicado detrás de un NAT o firewall. Actualmente admite TCP y UDP , así como los protocolos HTTP y HTTPS , lo que permite reenviar solicitudes a servicios internos a través del nombre de dominio.
frp también ofrece un modo de conexión P2P.
Estado de desarrollo
Acerca de V2
Arquitectura
Uso de ejemplo
Acceda a su computadora en una red LAN a través de SSH
Múltiples servicios SSH compartiendo el mismo puerto
Acceso a servicios web internos con dominios personalizados en LAN
Reenviar solicitudes de consulta de DNS
Socket de dominio Unix directo
Exponer un servidor de archivos HTTP simple
Habilite HTTPS para un servicio HTTP(S) local
Expone tu servicio de forma privada
Modo P2P
Características
HTTP X-reenviado-para
Protocolo de proxy
Para cada proxy
TLS
Autenticación de token
Autenticación OIDC
Prometeo
Archivos de configuración
Usar variables de entorno
Dividir configuraciones en diferentes archivos
Panel del servidor
Interfaz de usuario de administración del cliente
Monitor
Autenticar al cliente
Cifrado y compresión
Configuración de frpc de recarga en caliente
Obtener el estado del proxy del cliente
Permitir solo ciertos puertos en el servidor
Reutilización de puertos
Límite de ancho de banda
Multiplexación de flujo TCP
Admite protocolo KCP
Admite protocolo QUIC
Agrupación de conexiones
Equilibrio de carga
Comprobación del estado del servicio
Reescribir el encabezado del host HTTP
Configurar otros encabezados HTTP
Obtenga IP real
Requerir autenticación básica HTTP (contraseña) para servicios web
Nombres de subdominio personalizados
Enrutamiento de URL
Multiplexación de puertos TCP
Conexión a frps a través de PROXY
Mapeo de rango de puertos
Complementos de cliente
Complementos de administración del servidor
Puerta de enlace de túnel SSH
Proyectos Relacionados
Contribuyendo
Donación
Patrocinadores de GitHub
PayPal
frp está actualmente en desarrollo. Puede probar la última versión en la rama master o usar la rama dev para acceder a la versión actualmente en desarrollo.
Actualmente estamos trabajando en la versión 2 e intentando realizar algunas refactorizaciones y mejoras del código. Sin embargo, tenga en cuenta que no será compatible con la versión 1.
Realizaremos la transición de la versión 0 a la versión 1 en el momento adecuado y solo aceptaremos correcciones de errores y mejoras, en lugar de solicitudes de funciones importantes.
La complejidad y dificultad de la versión v2 son mucho mayores de lo previsto. Sólo puedo trabajar en su desarrollo durante períodos de tiempo fragmentados, y las constantes interrupciones alteran significativamente la productividad. Dada esta situación, continuaremos optimizando e iterando la versión actual hasta que tengamos más tiempo libre para continuar con la revisión principal de la versión.
El concepto detrás de v2 se basa en mis años de experiencia y reflexión en el dominio nativo de la nube, particularmente en K8 y ServiceMesh. Su núcleo es un proxy modernizado de cuatro y siete capas, similar al enviado. Este proxy en sí es altamente escalable, no sólo capaz de implementar la funcionalidad de penetración de intranet sino también aplicable a otros dominios. Sobre la base de este núcleo altamente escalable, nuestro objetivo es implementar todas las capacidades de frp v1 y al mismo tiempo abordar las funcionalidades que antes eran inalcanzables o difíciles de implementar de una manera elegante. Además, mantendremos capacidades eficientes de desarrollo e iteración.
Además, imagino que el propio FRP se convertirá en un sistema y una plataforma altamente extensible, similar a cómo podemos proporcionar una gama de capacidades de extensión basadas en K8. En K8, podemos personalizar el desarrollo según las necesidades de la empresa, utilizando funciones como CRD, modo de controlador, webhook, CSI y CNI. En frp v1, introdujimos el concepto de complementos de servidor, que implementaban cierta extensibilidad básica. Sin embargo, se basa en un protocolo HTTP simple y requiere que los usuarios inicien procesos independientes y los administren por su cuenta. Este enfoque está lejos de ser flexible y conveniente, y las demandas del mundo real varían mucho. No es realista esperar que un proyecto de código abierto sin fines de lucro mantenido por unas pocas personas satisfaga las necesidades de todos.
Finalmente, reconocemos que el diseño actual de módulos como gestión de configuración, verificación de permisos, gestión de certificados y gestión de API no es lo suficientemente moderno. Si bien es posible que llevemos a cabo algunas optimizaciones en la versión v1, garantizar la compatibilidad sigue siendo un problema desafiante que requiere un esfuerzo considerable para abordarlo.
Agradecemos sinceramente su apoyo a frp.
Para comenzar, descargue el programa más reciente para su sistema operativo y arquitectura desde la página de lanzamiento.
A continuación, coloque el archivo de configuración del servidor y binario frps en el servidor A, que tiene una dirección IP pública.
Finalmente, coloque el archivo de configuración del cliente y binario frpc en el servidor B, que está ubicado en una LAN a la que no se puede acceder directamente desde la Internet pública.
Algunos antivirus marcan incorrectamente frpc como malware y lo eliminan. Esto se debe a que frp es una herramienta de red capaz de crear servidores proxy inversos. Los antivirus a veces señalan los servidores proxy inversos debido a su capacidad para eludir las restricciones de los puertos del firewall. Si está utilizando un antivirus, es posible que deba incluir en la lista blanca/excluir frpc en la configuración de su antivirus para evitar la cuarentena/eliminación accidental. Consulte el número 3637 para obtener más detalles.
Modifique frps.toml en el servidor A configurando el bindPort para que los clientes frp se conecten:
#frps.tomlbindPort = 7000
Inicie frps en el servidor A:
./frps -c ./frps.toml
Modifique frpc.toml en el servidor B y establezca el campo serverAddr en la dirección IP pública de su servidor fps:
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[proxies]]name = "ssh"type = "tcp"localIP = "127.0.0.1"localPort = 22remotePort = 6000
Tenga en cuenta que el localPort (escuchado en el cliente) y remotePort (expuesto en el servidor) se utilizan para el tráfico que entra y sale del sistema frp, mientras que el serverPort se utiliza para la comunicación entre frps y frpc.
Inicie frpc en el servidor B:
./frpc -c ./frpc.toml
Para acceder al servidor B desde otra máquina a través del servidor A mediante SSH (suponiendo que el nombre de usuario sea test ), use el siguiente comando:
ssh -oPort=6000 test@xxxx
Este ejemplo implementa múltiples servicios SSH expuestos a través del mismo puerto usando un proxy de tipo tcpmux. De manera similar, siempre que el cliente admita el método de conexión proxy HTTP Connect, se puede lograr la reutilización de puertos de esta manera.
Implemente frps en una máquina con una IP pública y modifique el archivo frps.toml. Aquí hay una configuración simplificada:
bindPort = 7000tcpmuxHTTPConnectPort = 5002
Implemente frpc en la máquina interna A con la siguiente configuración:
serverAddr = "xxxx"serverPort = 7000[[proxies]]name = "ssh1"type = "tcpmux"multiplexer = "httpconnect"customDomains = ["machine-a.example.com"]localIP = "127.0.0.1"localPort = 22
Implemente otro frpc en la máquina interna B con la siguiente configuración:
serverAddr = "xxxx"serverPort = 7000[[proxies]]name = "ssh2"type = "tcpmux"multiplexer = "httpconnect"customDomains = ["machine-b.example.com"]localIP = "127.0.0.1"localPort = 22
Para acceder a la máquina interna A usando SSH ProxyCommand, asumiendo que el nombre de usuario es "prueba":
ssh -o 'proxycommand socat - PROXY:xxxx:%h:%p,proxyport=5002' [email protected]
Para acceder a la máquina interna B, la única diferencia es el nombre de dominio, asumiendo que el nombre de usuario es "prueba":
ssh -o 'proxycommand socat - PROXY:xxxx:%h:%p,proxyport=5002' [email protected]
A veces necesitamos exponer un servicio web local detrás de una red NAT a otros con fines de prueba con nuestro propio nombre de dominio.
Lamentablemente, no podemos resolver un nombre de dominio en una IP local. Sin embargo, podemos usar frp para exponer un servicio HTTP(S).
Modifique frps.toml y configure el puerto HTTP para vhost en 8080:
# frps.tomlbindPort = 7000vhostHTTPPort = 8080
Si desea configurar un proxy https, debe configurar vhostHTTPSPort .
Iniciar frps :
./frps -c ./frps.toml
Modifique frpc.toml y configure serverAddr en la dirección IP del servidor fps remoto. Especifique el localPort de su servicio web:
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[proxies]]name = "web"type = "http"localPort = 80customDomains = ["www.example.com"]
Iniciar frpc :
./frpc -c ./frpc.toml
Asigne el registro A de www.example.com a la IP pública del servidor frps remoto o a un registro CNAME que apunte a su dominio original.
Visite su servicio web local utilizando la URL http://www.example.com:8080 .
Modificar frps.toml :
#frps.tomlbindPort = 7000
Iniciar frps :
./frps -c ./frps.toml
Modifique frpc.toml y configure serverAddr en la dirección IP del servidor fps remoto. Reenviar solicitudes de consulta de DNS al servidor DNS público de Google 8.8.8.8:53 :
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[proxies]]name = "dns"type = "udp"localIP = "8.8.8.8"localPort = 53remotePort = 6000
Iniciar frpc:
./frpc -c ./frpc.toml
Pruebe la resolución de DNS usando el comando dig :
dig @xxxx -p 6000 www.google.com
Exponga un socket de dominio Unix (por ejemplo, el socket del demonio Docker) como TCP.
Configure frps como se indica arriba.
Inicie frpc con la siguiente configuración:
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[proxies]]name = "unix_domain_socket"type = "tcp"remotePort = 6000[proxies.plugin]type = "unix_domain_socket"unixPath = "/var/run/docker.sock "
Pruebe la configuración obteniendo la versión de Docker usando curl :
curl http://xxxx:6000/version
Exponga un servidor de archivos HTTP simple para acceder a archivos almacenados en la LAN desde la Internet pública.
Configure frps como se describe arriba, luego:
Inicie frpc con la siguiente configuración:
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[proxies]]name = "test_static_file"type = "tcp"remotePort = 6000[proxies.plugin]type = "static_file"localPath = "/tmp/files"stripPrefix = " estático"httpUsuario = "abc"httpContraseña = "abc"
Visite http://xxxx:6000/static/ desde su navegador y especifique el nombre de usuario y la contraseña correctos para ver los archivos en /tmp/files en la máquina frpc .
Puede sustituir https2https por el complemento y apuntar localAddr a un punto final HTTPS.
Inicie frpc con la siguiente configuración:
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[proxies]]name = "test_https2http"type = "https"customDomains = ["test.example.com"] [proxies.plugin]type = "https2http"localAddr = "127.0.0.1:80"crtPath = "./server.crt"keyPath = "./server.key"hostHeaderRewrite = "127.0.0.1"requestHeaders.set.x- desde-dónde = "frp"
Visite https://test.example.com .
Para mitigar los riesgos asociados con la exposición de ciertos servicios directamente a la red pública, el modo STCP (TCP secreto) requiere que se utilice una clave previamente compartida para acceder al servicio desde otros clientes.
Configure frps igual que arriba.
Inicie frpc en la máquina B con la siguiente configuración. Este ejemplo es para exponer el servicio SSH (puerto 22) y tenga en cuenta el campo secretKey para la clave previamente compartida y que el campo remotePort se elimina aquí:
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[proxies]]name = "secret_ssh"type = "stcp"secretKey = "abcdefg"localIP = "127.0.0.1"localPort = 22
Inicie otro frpc (normalmente en otra máquina C) con la siguiente configuración para acceder al servicio SSH con una clave de seguridad (campo secretKey ):
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[visitantes]]name = "secret_ssh_visitor"type = "stcp"serverName = "secret_ssh"secretKey = "abcdefg"bindAddr = "127.0.0.1"bindPort = 6000
En la máquina C, conéctese a SSH en la máquina B, usando este comando:
ssh -oPort=6000 127.0.0.1
xtcp está diseñado para transmitir grandes cantidades de datos directamente entre clientes. Aún se necesita un servidor frps, ya que aquí P2P solo se refiere a la transmisión de datos real.
Tenga en cuenta que es posible que no funcione con todos los tipos de dispositivos NAT. Es posible que desee recurrir a stcp si xtcp no funciona.
Inicie frpc en la máquina B y exponga el puerto SSH. Tenga en cuenta que el campo remotePort se elimina:
# frpc.tomlserverAddr = "xxxx"serverPort = 7000# configure un nuevo servidor de aturdimiento si el predeterminado no está disponible.# natHoleStunServer = "xxx"[[proxies]]name = "p2p_ssh"type = "xtcp"secretKey = " abcdefg"localIP = "127.0.0.1"localPort = 22
Inicie otro frpc (normalmente en otra máquina C) con la configuración para conectarse a SSH usando el modo P2P:
# frpc.tomlserverAddr = "xxxx"serverPort = 7000# configure un nuevo servidor de aturdimiento si el predeterminado no está disponible.# natHoleStunServer = "xxx"[[visitors]]name = "p2p_ssh_visitor"type = "xtcp"serverName = " p2p_ssh"secretKey = "abcdefg"bindAddr = "127.0.0.1"bindPort = 6000# cuando se requiere persistencia automática del túnel, configúrelo en truekeepTunnelOpen = false
En la máquina C, conéctese a SSH en la máquina B, usando este comando:
ssh -oPort=6000 127.0.0.1
Desde v0.52.0, admitimos TOML, YAML y JSON para la configuración. Tenga en cuenta que INI está en desuso y se eliminará en versiones futuras. Las nuevas funciones solo estarán disponibles en TOML, YAML o JSON. Los usuarios que deseen estas nuevas funciones deben cambiar su formato de configuración en consecuencia.
Lea los archivos de configuración de ejemplo completos para descubrir aún más funciones que no se describen aquí.
Los ejemplos usan el formato TOML, pero aún puedes usar YAML o JSON.
Estos archivos de configuración son solo de referencia. No utilice esta configuración directamente para ejecutar el programa, ya que puede tener varios problemas.
Archivo de configuración completo para frps (Servidor)
Archivo de configuración completo para frpc (Cliente)
Se puede hacer referencia a las variables de entorno en el archivo de configuración, utilizando el formato estándar de Go:
# frpc.tomlserverAddr = "{{ .Envs.FRP_SERVER_ADDR }}"serverPort = 7000[[proxies]]name = "ssh"type = "tcp"localIP = "127.0.0.1"localPort = 22remotePort = "{{ .Envs. FRP_SSH_REMOTE_PORT }}" Con la configuración anterior, las variables se pueden pasar al programa frpc de esta manera:
export FRP_SERVER_ADDR=x.x.x.x export FRP_SSH_REMOTE_PORT=6000 ./frpc -c ./frpc.toml
frpc representará la plantilla del archivo de configuración utilizando variables de entorno del sistema operativo. Recuerde anteponer su referencia con .Envs .
Puede dividir varias configuraciones de proxy en diferentes archivos e incluirlas en el archivo principal.
# frpc.tomlserverAddr = "xxxx"serverPort = 7000includes = ["./confd/*.toml"]
# ./confd/test.toml[[proxies]]name = "ssh"type = "tcp"localIP = "127.0.0.1"localPort = 22remotePort = 6000
Verifique el estado de frp y la información estadística de los servidores proxy mediante el Panel de control.
Configure un puerto para el panel para habilitar esta función:
# El valor predeterminado es 127.0.0.1. Cámbielo a 0.0.0.0 cuando desee acceder a él desde una red pública.webServer.addr = "0.0.0.0"webServer.port = 7500# El nombre de usuario y la contraseña del panel son opcionaleswebServer.user = "admin"webServer.password = " administración"
Luego visite http://[serverAddr]:7500 para ver el panel, con el nombre de usuario y la contraseña como admin .
Además, puede utilizar el puerto HTTPS utilizando el comodín de su dominio o un certificado SSL normal:
webServer.port = 7500# el nombre de usuario y la contraseña del panel son opcionaleswebServer.user = "admin"webServer.password = "admin"webServer.tls.certFile = "server.crt"webServer.tls.keyFile = "server.key"
Luego visite https://[serverAddr]:7500 para ver el panel en una conexión HTTPS segura, con el nombre de usuario y la contraseña como admin .
La interfaz de usuario de Client Admin le ayuda a comprobar y gestionar la configuración de frpc.
Configure una dirección para la interfaz de usuario del administrador para habilitar esta función:
webServer.addr = "127.0.0.1"webServer.port = 7400webServer.user = "admin"webServer.password = "admin"
Luego visite http://127.0.0.1:7400 para ver la interfaz de usuario del administrador, donde el nombre de usuario y la contraseña son admin .
Cuando el servidor web está habilitado, frps guardará los datos del monitor en la caché durante 7 días. Se borrará después de reiniciar el proceso.
Prometeo también es compatible.
Primero habilite el panel, luego configure enablePrometheus = true en frps.toml .
http://{dashboard_addr}/metrics proporcionará datos del monitor Prometheus.
Existen 2 métodos de autenticación para autenticar frpc con frps.
Puede decidir cuál usar configurando auth.method en frpc.toml y frps.toml , el predeterminado es token.
La configuración de auth.additionalScopes = ["HeartBeats"] utilizará el método de autenticación configurado para agregar y validar la autenticación en cada latido entre frpc y frps.
La configuración de auth.additionalScopes = ["NewWorkConns"] hará lo mismo para cada nueva conexión de trabajo entre frpc y frps.
Al especificar auth.method = "token" en frpc.toml y frps.toml , se utilizará la autenticación basada en token.
Asegúrese de especificar el mismo auth.token en frps.toml y frpc.toml para que frpc pase la validación de frps
Al especificar auth.method = "oidc" en frpc.toml y frps.toml , se utilizará la autenticación basada en OIDC.
OIDC significa OpenID Connect y el flujo utilizado se llama Concesión de credenciales de cliente.
Para utilizar este tipo de autenticación, configure frpc.toml y frps.toml de la siguiente manera:
# frps.tomlauth.method = "oidc"auth.oidc.issuer = "https://example-oidc-issuer.com/"auth.oidc.audience = "https://oidc-audience.com/.default"
# frpc.tomlauth.method = "oidc"auth.oidc.clientID = "98692467-37de-409a-9fac-bb2585826f18" # Reemplazar con el cliente OIDC IDauth.oidc.clientSecret = "oidc_secret"auth.oidc.audience = "https: //oidc-audience.com/.default"auth.oidc.tokenEndpointURL = "https://example-oidc-endpoint.com/oauth2/v2.0/token"
Las funciones están desactivadas de forma predeterminada. Puede activar el cifrado y/o la compresión:
# frpc.toml[[proxies]]name = "ssh"type = "tcp"localPort = 22remotePort = 6000transport.useEncryption = truetransport.useCompression = true
Desde v0.50.0, el valor predeterminado de transport.tls.enable y transport.tls.disableCustomTLSFirstByte se cambió a verdadero y tls está habilitado de forma predeterminada.
Para la multiplexación de puertos, frp envía un primer byte 0x17 para marcar una conexión TLS. Esto solo tiene efecto cuando configura transport.tls.disableCustomTLSFirstByte en falso.
Para hacer que frps solo acepte conexiones TLS, configure transport.tls.force = true en frps.toml . Esto es opcional.
Configuración de frpc TLS:
transport.tls.enable = truetransport.tls.certFile = "certificado.crt"transport.tls.keyFile = "certificado.key"transport.tls.trustedCaFile = "ca.crt"
Configuración de frps TLS:
transport.tls.force = truetransport.tls.certFile = "certificado.crt"transport.tls.keyFile = "certificado.key"transport.tls.trustedCaFile = "ca.crt"
Necesitará un certificado de CA raíz y al menos un certificado SSL/TLS . Puede ser autofirmado o normal (como Let's Encrypt u otro proveedor de certificados SSL/TLS).
Si utiliza frp a través de la dirección IP y no del nombre de host, asegúrese de configurar la dirección IP adecuada en el área Nombre alternativo del sujeto (SAN) al generar certificados SSL/TLS.
Dado un ejemplo:
Prepare el archivo de configuración openssl. Existe en /etc/pki/tls/openssl.cnf en el sistema Linux y /System/Library/OpenSSL/openssl.cnf en MacOS, y puede copiarlo a la ruta actual, como cp /etc/pki/tls/openssl.cnf ./my-openssl.cnf . Si no, puedes construirlo tú mismo, como:
cat > my-openssl.cnf << EOF [ ca ] default_ca = CA_default [ CA_default ] x509_extensions = usr_cert [ req ] default_bits = 2048 default_md = sha256 default_keyfile = privkey.pem distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca string_mask = utf8only [ req_distinguished_name ] [ req_attributes ] [ usr_cert ] basicConstraints = CA:FALSE nsComment = "OpenSSL Generated Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer [ v3_ca ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = CA:true EOF
construir certificados ca:
openssl genrsa -out ca.key 2048 openssl req -x509 -new -nodes -key ca.key -subj "/CN=example.ca.com" -days 5000 -out ca.crt
construir certificados frps:
openssl genrsa -out server.key 2048 openssl req -new -sha256 -key server.key -subj "/C=XX/ST=DEFAULT/L=DEFAULT/O=DEFAULT/CN=server.com" -reqexts SAN -config <(cat my-openssl.cnf <(printf "n[SAN]nsubjectAltName=DNS:localhost,IP:127.0.0.1,DNS:example.server.com")) -out server.csr openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -extfile <(printf "subjectAltName=DNS:localhost,IP:127.0.0.1,DNS:example.server.com") -out server.crt
construir certificados frpc:
openssl genrsa -out client.key 2048 openssl req -new -sha256 -key client.key -subj "/C=XX/ST=DEFAULT/L=DEFAULT/O=DEFAULT/CN=client.com" -reqexts SAN -config <(cat my-openssl.cnf <(printf "n[SAN]nsubjectAltName=DNS:client.com,DNS:example.client.com")) -out client.csr openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -extfile <(printf "subjectAltName=DNS:client.com,DNS:example.client.com") -out client.crt
Los campos webServer son obligatorios para habilitar la API HTTP:
# frpc.tomlwebServer.addr = "127.0.0.1"webServer.port = 7400
Luego ejecute el comando frpc reload -c ./frpc.toml y espere unos 10 segundos para permitir que frpc cree, actualice o elimine servidores proxy.
Tenga en cuenta que los parámetros globales del cliente no se modificarán excepto el "inicio".
Puede ejecutar el comando frpc verify -c ./frpc.toml antes de recargar para verificar si hay errores de configuración.
Utilice frpc status -c ./frpc.toml para obtener el estado de todos los servidores proxy. Los campos webServer son obligatorios para habilitar la API HTTP.
allowPorts en frps.toml se utiliza para evitar el abuso de puertos:
#frps.tomlallowPorts = [
{inicio = 2000, fin = 3000},
{soltero = 3001},
{soltero = 3003},
{ inicio = 4000, final = 50000 }
] vhostHTTPPort y vhostHTTPSPort en frps pueden usar el mismo puerto con bindPort . frps detectará el protocolo de conexión y lo manejará en consecuencia.
A lo que debe prestar atención es que si desea configurar vhostHTTPSPort y bindPort en el mismo puerto, primero debe configurar transport.tls.disableCustomTLSFirstByte en falso.
Nos gustaría intentar permitir que varios servidores proxy vinculen un mismo puerto remoto con diferentes protocolos en el futuro.
# frpc.toml[[proxies]]name = "ssh"type = "tcp"localPort = 22remotePort = 6000transport.bandwidthLimit = "1MB"
Establezca transport.bandwidthLimit en la configuración de cada proxy para habilitar esta función. Las unidades admitidas son MB y KB .
Establezca transport.bandwidthLimitMode en client o server para limitar el ancho de banda en el lado del cliente o del servidor. El valor predeterminado es client .
frp admite la multiplexación de flujos tcp desde v0.10.0 como la multiplexación HTTP2, en cuyo caso todas las conexiones lógicas al mismo frpc se multiplexan en la misma conexión TCP.
Puede desactivar esta función modificando frps.toml y frpc.toml :
# frps.toml y frpc.toml, deben ser igualestransport.tcpMux = false
KCP es un protocolo rápido y confiable que puede lograr el efecto de transmisión de una reducción de la latencia promedio entre un 30 % y un 40 % y una reducción del retraso máximo en un factor de tres, a costa de un 10 % a un 20 % más de ancho de banda desperdiciado. que TCP.
El modo KCP utiliza UDP como transporte subyacente. Usando KCP en frp:
Habilite KCP en frps:
# frps.tomlbindPort = 7000# Especifique un puerto UDP para KCP.kcpBindPort = 7000
El número kcpBindPort puede ser el mismo número que bindPort , ya que el campo bindPort especifica un puerto TCP.
Configure frpc.toml para usar KCP para conectarse a frps:
# frpc.tomlserverAddr = "xxxx"# Igual que 'kcpBindPort' en frps.tomlserverPort = 7000transport.protocol = "kcp"
QUIC es un nuevo transporte multiplexado construido sobre UDP.
Usando QUIC en frp:
Habilite QUIC en frps:
# frps.tomlbindPort = 7000# Especifique un puerto UDP para QUIC.quicBindPort = 7000
El número quicBindPort puede ser el mismo número que bindPort , ya que el campo bindPort especifica un puerto TCP.
Configure frpc.toml para usar QUIC para conectarse a frps:
# frpc.tomlserverAddr = "xxxx"# Igual que 'quicBindPort' en frps.tomlserverPort = 7000transport.protocol = "quic"
De forma predeterminada, frps crea una nueva conexión frpc al servicio backend a petición del usuario. Con la agrupación de conexiones, frps mantiene una cierta cantidad de conexiones preestablecidas, lo que reduce el tiempo necesario para establecer una conexión.
Esta característica es adecuada para una gran cantidad de conexiones cortas.
Configure el límite de recuento de grupos que cada proxy puede usar en frps.toml :
#frps.tomltransport.maxPoolCount = 5
Habilite y especifique el número de grupo de conexiones:
# frpc.tomltransport.poolCount = 1
El equilibrio de carga es compatible con group .
Esta función ahora solo está disponible para los tipos tcp , http , tcpmux .
# frpc.toml[[proxies]]name = "test1"type = "tcp"localPort = 8080remotePort = 80loadBalancer.group = "web"loadBalancer.groupKey = "123"[[proxies]]name = "test2"type = " tcp"localPort = 8081remotePort = 80loadBalancer.group = "web"loadBalancer.groupKey = "123"
loadBalancer.groupKey se utiliza para la autenticación.
Las conexiones al puerto 80 se enviarán a los servidores proxy del mismo grupo de forma aleatoria.
Para el tipo tcp , remotePort en el mismo grupo debe ser el mismo.
Para el tipo http , customDomains y subdomain , locations deben ser las mismas.
La función de verificación de estado puede ayudarlo a lograr una alta disponibilidad con el equilibrio de carga.
Agregue healthCheck.type = "tcp" o healthCheck.type = "http" para habilitar la verificación de estado.
Con el tipo de verificación de estado tcp , se hará ping al puerto de servicio (TCPing):
# frpc.toml[[proxies]]name = "test1"type = "tcp"localPort = 22remotePort = 6000# Habilitar verificación de estado de TCPhealthCheck.type = "tcp"# Tiempo de espera de TCP segundoshealthCheck.timeoutSeconds = 3# Si la verificación de estado falló 3 veces seguidos, el proxy se eliminará de frpshealthCheck.maxFailed = 3# Un control de estado cada 10 segundoshealthCheck.intervalSeconds = 10
Con el tipo de verificación de estado http , se enviará una solicitud HTTP al servicio y se espera una respuesta HTTP 2xx OK:
# frpc.toml[[proxies]]name = "web"type = "http"localIP = "127.0.0.1"localPort = 80customDomains = ["test.example.com"]# Habilitar comprobación de estado HTTPhealthCheck.type = "http" # frpc enviará una solicitud GET a '/status'# y esperará una respuesta HTTP 2xx OKhealthCheck.path = "/status"healthCheck.timeoutSeconds = 3healthCheck.maxFailed = 3healthCheck.intervalSeconds = 10
De forma predeterminada, frp no modifica en absoluto las solicitudes HTTP tunelizadas, ya que es una copia byte por byte.
Sin embargo, hablando de servidores web y solicitudes HTTP, su servidor web puede depender del encabezado HTTP Host para determinar el sitio web al que se accederá. frp puede reescribir el encabezado Host al reenviar las solicitudes HTTP, con el campo hostHeaderRewrite :
# frpc.toml[[proxies]]name = "web"type = "http"localPort = 80customDomains = ["test.example.com"]hostHeaderRewrite = "dev.example.com"
La solicitud HTTP tendrá el encabezado Host reescrito en Host: dev.example.com cuando llegue al servidor web real, aunque la solicitud del navegador probablemente tenga Host: test.example.com .
De manera similar a Host , puede anular otras solicitudes HTTP y encabezados de respuesta con el tipo de proxy http .
# frpc.toml[[proxies]]name = "web"type = "http"localPort = 80customDomains = ["test.example.com"]hostHeaderRewrite = "dev.example.com"requestHeaders.set.x-from-where = "frp"responseHeaders.set.foo = "barra"
En este ejemplo, establecerá el encabezado x-from-where: frp en la solicitud HTTP y foo: bar en la respuesta HTTP.
Esta función es para servidores proxy http o servidores proxy con los complementos https2http y https2https habilitados.
Puede obtener la IP real del usuario a partir de los encabezados de solicitud HTTP X-Forwarded-For .
frp admite el protocolo Proxy para enviar la IP real del usuario a los servicios locales. Admite todos los tipos excepto UDP.
A continuación se muestra un ejemplo de servicio https:
# frpc.toml[[proxies]]name = "web"type = "https"localPort = 443customDomains = ["test.example.com"]# ahora se admiten v1 y v2transport.proxyProtocolVersion = "v2"
Puede habilitar la compatibilidad con el protocolo Proxy en nginx para exponer la IP real del usuario en el encabezado HTTP X-Real-IP y luego leer el encabezado X-Real-IP en su servicio web para obtener la IP real.
Cualquiera que pueda adivinar la URL de su túnel puede acceder a su servidor web local a menos que lo proteja con una contraseña.
Esto aplica la autenticación básica HTTP en todas las solicitudes con el nombre de usuario y la contraseña especificados en el archivo de configuración de frpc.
Sólo se puede habilitar cuando el tipo de proxy es http.
# frpc.toml[[proxies]]nombre = "web"tipo = "http"localPort = 80customDomains = ["test.example.com"]httpUser = "abc"httpContraseña = "abc"
Visite http://test.example.com en el navegador y ahora se le pedirá que ingrese el nombre de usuario y la contraseña.
Es conveniente utilizar la configuración subdomain para los tipos http y https cuando muchas personas comparten un servidor frps.
# frps.tomlsubDomainHost = "frps.com"
Resuelva *.frps.com en la IP del servidor frps. Esto suele denominarse registro DNS comodín.
# frpc.toml[[proxies]]nombre = "web"tipo = "http"localPort = 80subdominio = "prueba"
Ahora puede visitar su servicio web en test.frps.com .
Tenga en cuenta que si subdomainHost no está vacío, customDomains no debería ser el subdominio de subdomainHost .
frp admite el reenvío de solicitudes HTTP a diferentes servicios web backend mediante enrutamiento de URL.
locations especifica el prefijo de la URL utilizada para el enrutamiento. frps primero busca la ubicación del prefijo más específica dada por cadenas literales independientemente del orden listado.
# frpc.toml[[proxies]]nombre = "web01"tipo = "http"localPort = 80customDomains = ["web.example.com"]ubicaciones = ["/"] [[proxies]]nombre = "web02"tipo = "http"localPort = 81customDomains = ["web.example.com"]ubicaciones = ["/news", "/about"]
Las solicitudes HTTP con el prefijo de URL /news o /about se reenviarán a web02 y otras solicitudes a web01 .
frp admite la recepción de sockets TCP dirigidos a diferentes servidores proxy en un único puerto en frp, similar a vhostHTTPPort y vhostHTTPSPort .
El único método de multiplexación de puertos TCP compatible disponible en este momento es httpconnect - túnel HTTP CONNECT.
Al configurar tcpmuxHTTPConnectPort en un valor distinto de 0 en frps, frps escuchará en este puerto las solicitudes HTTP CONNECT.
El host de la solicitud HTTP CONNECT se utilizará para hacer coincidir el proxy en frps. Los hosts proxy se pueden configurar en frpc configurando customDomains y/o subdomain en servidores tcpmux , cuando multiplexer = "httpconnect" .
Por ejemplo:
# frps.tomlbindPort = 7000tcpmuxHTTPConnectPort = 1337
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[proxies]]name = "proxy1"type = "tcpmux"multiplexer = "httpconnect"customDomains = ["test1"]localPort = 80[[proxies]]name = "proxy2 "type = "tcpmux"multiplexer = "httpconnect"customDomains = ["test2"]localPort = 8080
En la configuración anterior, se puede contactar a frps en el puerto 1337 con un encabezado HTTP CONNECT como:
CONNECT test1 HTTP/1.1rnrn
y la conexión se enrutará a proxy1 .
frpc puede conectarse a frps a través de proxy si configura la variable de entorno del sistema operativo HTTP_PROXY , o si transport.proxyURL está configurado en el archivo frpc.toml.
Sólo funciona cuando el protocolo es tcp.
# frpc.tomlserverAddr = "xxxx"serverPort = 7000transport.proxyURL = "http://user:[email protected]:8080"
Agregado en v0.56.0
Podemos usar la sintaxis de rango de la plantilla Go combinada con la función parseNumberRangePair incorporada para lograr el mapeo de rango de puertos.
El siguiente ejemplo, cuando se ejecute, creará 8 servidores proxy llamados test-6000, test-6001 ... test-6007 , cada uno de los cuales asignará el puerto remoto al puerto local.
{{- range $_, $v := parseNumberRangePair "6000-6006,6007" "6000-6006,6007" }}
[[proxies]]
name = "tcp-{{ $v.First }}"
type = "tcp"
localPort = {{ $v.First }}
remotePort = {{ $v.Second }}
{{- end }}frpc solo reenvía solicitudes a puertos TCP o UDP locales de forma predeterminada.
Los complementos se utilizan para proporcionar funciones avanzadas. Hay complementos integrados como unix_domain_socket , http_proxy , socks5 , static_file , http2https , https2http , https2https y puede ver ejemplos de uso.
Usando el complemento http_proxy :
# frpc.toml[[proxies]]name = "http_proxy"type = "tcp"remotePort = 6000[proxies.plugin]type = "http_proxy"httpUser = "abc"httpContraseña = "abc"
httpUser y httpPassword son parámetros de configuración utilizados en el complemento http_proxy .
Lea el documento.
Encuentre más complementos en gofrp/plugin.
añadido en v0.53.0
frp admite escuchar un puerto SSH en el lado de frps y logra el proxy del protocolo TCP a través del protocolo SSH -R, sin depender de frpc.
# frps.tomlsshTunnelGateway.bindPort = 2200
Al ejecutar ./frps -c frps.toml , se creará automáticamente un archivo de clave privada llamado .autogen_ssh_key en el directorio de trabajo actual. Este archivo de clave privada generado será utilizado por el servidor SSH en frps.
Ejecutando el comando
ssh -R :80:127.0.0.1:8080 v0@{dirección frp} -p 2200 tcp --proxy_name "test-tcp" --remote_port 9090configura un proxy en frp que reenvía el servicio local 8080 al puerto 9090.
frp (a través de SSH) (Ctrl+C para salir) Usuario: Nombre de proxy: prueba-tcp Tipo: TCP Dirección remota: :9090
Esto equivale a:
frpc tcp --proxy_name "test-tcp" --local_ip 127.0.0.1 --local_port 8080 --remote_port 9090
Consulte este documento para obtener más información.
gofrp/plugin: un repositorio de complementos de frp que contiene una variedad de complementos implementados en función del mecanismo de extensión de frp, que satisface las necesidades de personalización de diferentes escenarios.
gofrp/tiny-frpc: una versión liviana del cliente frp (alrededor de 3,5 MB como mínimo) implementada mediante el protocolo ssh, que admite algunas de las funciones más utilizadas y es adecuada para dispositivos con recursos limitados.
¿Interesado en involucrarse? ¡Nos gustaría ayudarte!
Eche un vistazo a nuestra lista de problemas y considere enviar una solicitud de extracción a la rama de desarrollo .
Si desea agregar una nueva característica, primero cree un problema para describir la nueva característica, así como el enfoque de implementación. Una vez que se acepte una propuesta, cree una implementación de las nuevas funciones y envíela como una solicitud de extracción.
Perdón por mi pobre inglés. Se agradecen las mejoras a este documento, incluso algunas correcciones de errores tipográficos.
Si tiene grandes ideas, envíe un correo electrónico a [email protected].
Nota: Preferimos que usted brinde sus consejos sobre los problemas, para que otras personas con la misma pregunta puedan buscarla rápidamente y no tengamos que responderles repetidamente.
Si frp te ayuda mucho, puedes apoyarnos mediante:
Apóyanos con los patrocinadores de Github.
Puede colocar el logotipo de su empresa en el archivo README de este proyecto.
Donar dinero por PayPal a mi cuenta [email protected] .
