frp
0.61.0
LISEZMOI | 中文文档
frp est un projet open source dont le développement continu est entièrement rendu possible grâce au soutien de nos formidables sponsors. Si vous souhaitez les rejoindre, pensez à sponsoriser le développement de frp.
frp est un proxy inverse rapide qui vous permet d'exposer à Internet un serveur local situé derrière un NAT ou un pare-feu. Il prend actuellement en charge TCP et UDP , ainsi que les protocoles HTTP et HTTPS , permettant de transmettre les requêtes aux services internes via un nom de domaine.
frp propose également un mode de connexion P2P.
Statut de développement
À propos de la V2
Architecture
Exemple d'utilisation
Accédez à votre ordinateur dans un réseau LAN via SSH
Plusieurs services SSH partageant le même port
Accès aux services Web internes avec des domaines personnalisés dans le réseau local
Transférer les requêtes de requête DNS
Transférer le socket de domaine Unix
Exposer un simple serveur de fichiers HTTP
Activer HTTPS pour un service HTTP(S) local
Exposez votre service en privé
Mode P2P
Caractéristiques
HTTP X-Forwarded-For
Protocole proxy
Pour chaque proxy
TLS
Authentification par jeton
Authentification OIDC
Prométhée
Fichiers de configuration
Utilisation de variables d'environnement
Diviser les configurations en différents fichiers
Tableau de bord du serveur
Interface utilisateur d'administration client
Moniteur
Authentification du client
Cryptage et compression
Configuration frpc de rechargement à chaud
Obtenir le statut de proxy du client
Autoriser uniquement certains ports sur le serveur
Réutilisation des ports
Limite de bande passante
Multiplexage de flux TCP
Prise en charge du protocole KCP
Prise en charge du protocole QUIC
Regroupement de connexions
Équilibrage de charge
Bilan de santé du service
Réécriture de l'en-tête de l'hôte HTTP
Définition d'autres en-têtes HTTP
Obtenez une vraie IP
Exiger l'authentification de base HTTP (mot de passe) pour les services Web
Noms de sous-domaines personnalisés
Routage d'URL
Multiplexage de ports TCP
Connexion à frps via PROXY
Mappage de plage de ports
Plugins clients
Plugins de gestion du serveur
Passerelle de tunnel SSH
Projets connexes
Contribuer
Donation
Commanditaires GitHub
Paypal
frp est actuellement en cours de développement. Vous pouvez essayer la dernière version dans la branche master ou utiliser la branche dev pour accéder à la version actuellement en développement.
Nous travaillons actuellement sur la version 2 et essayons d'effectuer quelques refactorisations et améliorations du code. Attention cependant, il ne sera pas compatible avec la version 1.
Nous passerons de la version 0 à la version 1 au moment opportun et n'accepterons que les corrections de bugs et les améliorations, plutôt que les demandes de fonctionnalités importantes.
La complexité et la difficulté de la version v2 sont bien plus élevées que prévu. Je ne peux travailler à son développement que sur des périodes fragmentées, et les interruptions constantes perturbent considérablement la productivité. Compte tenu de cette situation, nous continuerons à optimiser et à itérer sur la version actuelle jusqu'à ce que nous ayons plus de temps libre pour procéder à la refonte majeure de la version.
Le concept derrière la v2 est basé sur mes années d'expérience et de réflexion dans le domaine du cloud natif, notamment dans K8s et ServiceMesh. Son noyau est un proxy modernisé à quatre et sept couches, similaire à Envoy. Ce proxy lui-même est hautement évolutif, non seulement capable de mettre en œuvre la fonctionnalité de pénétration intranet, mais également applicable à divers autres domaines. En nous appuyant sur ce noyau hautement évolutif, nous visons à implémenter toutes les capacités de frp v1 tout en abordant également les fonctionnalités qui étaient auparavant irréalisables ou difficiles à implémenter de manière élégante. De plus, nous maintiendrons des capacités efficaces de développement et d’itération.
De plus, j'imagine que frp lui-même deviendra un système et une plate-forme hautement extensibles, de la même manière que nous pouvons fournir une gamme de capacités d'extension basées sur K8. Dans K8, nous pouvons personnaliser le développement en fonction des besoins de l'entreprise, en utilisant des fonctionnalités telles que CRD, le mode contrôleur, le webhook, CSI et CNI. Dans frp v1, nous avons introduit le concept de plugins de serveur, qui implémentent une certaine extensibilité de base. Cependant, il repose sur un protocole HTTP simple et oblige les utilisateurs à démarrer des processus indépendants et à les gérer eux-mêmes. Cette approche est loin d’être flexible et pratique, et les exigences du monde réel varient considérablement. Il n'est pas réaliste de s'attendre à ce qu'un projet open source à but non lucratif, géré par quelques individus, réponde aux besoins de chacun.
Enfin, nous reconnaissons que la conception actuelle des modules tels que la gestion de la configuration, la vérification des autorisations, la gestion des certificats et la gestion des API n'est pas assez moderne. Bien que nous puissions effectuer quelques optimisations dans la version v1, assurer la compatibilité reste un problème difficile qui nécessite des efforts considérables pour être résolu.
Nous apprécions sincèrement votre soutien à frp.
Pour commencer, téléchargez le dernier programme correspondant à votre système d'exploitation et à votre architecture à partir de la page Release.
Ensuite, placez le binaire frps et le fichier de configuration du serveur sur le serveur A, qui possède une adresse IP publique.
Enfin, placez le fichier binaire frpc et le fichier de configuration client sur le serveur B, qui se trouve sur un réseau local auquel il n'est pas possible d'accéder directement depuis l'Internet public.
Certains antivirus marquent à tort frpc comme malware et le suppriment. Cela est dû au fait que frp est un outil réseau capable de créer des proxys inverses. Les antivirus signalent parfois les proxys inverses en raison de leur capacité à contourner les restrictions de port du pare-feu. Si vous utilisez un antivirus, vous devrez peut-être ajouter/exclure frpc dans vos paramètres antivirus pour éviter une mise en quarantaine/suppression accidentelle. Voir le numéro 3637 pour plus de détails.
Modifiez frps.toml sur le serveur A en définissant le bindPort auquel les clients frp doivent se connecter :
# frps.tomlbindPort = 7000
Démarrez frps sur le serveur A :
./frps -c ./frps.toml
Modifiez frpc.toml sur le serveur B et définissez le champ serverAddr sur l'adresse IP publique de votre serveur frps :
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[proxies]]name = "ssh"type = "tcp"localIP = "127.0.0.1"localPort = 22remotePort = 6000
Notez que le localPort (écouté sur le client) et remotePort (exposé sur le serveur) sont utilisés pour le trafic entrant et sortant du système frp, tandis que le serverPort est utilisé pour la communication entre frps et frpc.
Démarrez frpc sur le serveur B :
./frpc -c ./frpc.toml
Pour accéder au serveur B depuis une autre machine via le serveur A via SSH (en supposant que le nom d'utilisateur est test ), utilisez la commande suivante :
ssh -oPort=6000 test@xxxx
Cet exemple implémente plusieurs services SSH exposés via le même port à l'aide d'un proxy de type tcpmux. De même, tant que le client prend en charge la méthode de connexion proxy HTTP Connect, la réutilisation des ports peut être réalisée de cette manière.
Déployez frps sur une machine avec une IP publique et modifiez le fichier frps.toml. Voici une configuration simplifiée :
bindPort = 7000tcpmuxHTTPConnectPort = 5002
Déployez frpc sur la machine interne A avec la configuration suivante :
serverAddr = "xxxx"serverPort = 7000[[proxies]]name = "ssh1"type = "tcpmux"multiplexer = "httpconnect"customDomains = ["machine-a.example.com"]localIP = "127.0.0.1"localPort = 22
Déployez un autre frpc sur la machine interne B avec la configuration suivante :
serverAddr = "xxxx"serverPort = 7000[[proxies]]name = "ssh2"type = "tcpmux"multiplexer = "httpconnect"customDomains = ["machine-b.example.com"]localIP = "127.0.0.1"localPort = 22
Pour accéder à la machine interne A à l'aide de SSH ProxyCommand, en supposant que le nom d'utilisateur est "test" :
ssh -o 'proxycommand socat - PROXY:xxxx:%h:%p,proxyport=5002' [email protected]
Pour accéder à la machine interne B, la seule différence est le nom de domaine, en supposant que le nom d'utilisateur soit "test" :
ssh -o 'proxycommand socat - PROXY:xxxx:%h:%p,proxyport=5002' [email protected]
Parfois, nous devons exposer un service Web local derrière un réseau NAT à d'autres à des fins de test avec notre propre nom de domaine.
Malheureusement, nous ne pouvons pas résoudre un nom de domaine en une adresse IP locale. Cependant, nous pouvons utiliser frp pour exposer un service HTTP(S).
Modifiez frps.toml et définissez le port HTTP pour vhost sur 8080 :
# frps.tomlbindPort = 7000vhostHTTPPort = 8080
Si vous souhaitez configurer un proxy https, vous devez configurer le vhostHTTPSPort .
Démarrer frps :
./frps -c ./frps.toml
Modifiez frpc.toml et définissez serverAddr sur l'adresse IP du serveur frps distant. Spécifiez le localPort de votre service Web :
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[proxies]]name = "web"type = "http"localPort = 80customDomains = ["www.example.com"]
Démarrez frpc :
./frpc -c ./frpc.toml
Mappez l'enregistrement A de www.example.com soit à l'adresse IP publique du serveur frps distant, soit à un enregistrement CNAME pointant vers votre domaine d'origine.
Visitez votre service Web local en utilisant l'URL http://www.example.com:8080 .
Modifier frps.toml :
# frps.tomlbindPort = 7000
Démarrer frps :
./frps -c ./frps.toml
Modifiez frpc.toml et définissez serverAddr sur l'adresse IP du serveur frps distant. Transférer les requêtes de requête DNS au serveur DNS public 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
Démarrez frpc :
./frpc -c ./frpc.toml
Testez la résolution DNS à l'aide de la commande dig :
dig @xxxx -p 6000 www.google.com
Exposez un socket de domaine Unix (par exemple le socket du démon Docker) en tant que TCP.
Configurez frps comme ci-dessus.
Démarrez frpc avec la configuration suivante :
# 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 "
Testez la configuration en récupérant la version docker en utilisant curl :
curl http://xxxx:6000/version
Exposez un simple serveur de fichiers HTTP pour accéder aux fichiers stockés sur le réseau local à partir de l'Internet public.
Configurez frps comme décrit ci-dessus, puis :
Démarrez frpc avec la configuration suivante :
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[proxies]]name = "test_static_file"type = "tcp"remotePort = 6000[proxies.plugin]type = "static_file"localPath = "/tmp/files"stripPrefix = " statique"httpUser = "abc"httpPassword = "abc"
Visitez http://xxxx:6000/static/ depuis votre navigateur et spécifiez le nom d'utilisateur et le mot de passe corrects pour afficher les fichiers dans /tmp/files sur la machine frpc .
Vous pouvez remplacer https2https par le plugin et pointer localAddr vers un point de terminaison HTTPS.
Démarrez frpc avec la configuration suivante :
# 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- d'où = "frp"
Visitez https://test.example.com .
Pour atténuer les risques associés à l'exposition de certains services directement au réseau public, le mode STCP (Secret TCP) nécessite qu'une clé pré-partagée soit utilisée pour accéder au service à partir d'autres clients.
Configurez frps comme ci-dessus.
Démarrez frpc sur la machine B avec la configuration suivante. Cet exemple permet d'exposer le service SSH (port 22), et notez le champ secretKey pour la clé pré-partagée, et que le champ remotePort est supprimé ici :
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[proxies]]name = "secret_ssh"type = "stcp"secretKey = "abcdefg"localIP = "127.0.0.1"localPort = 22
Démarrez un autre frpc (généralement sur une autre machine C) avec la configuration suivante pour accéder au service SSH avec une clé de sécurité (champ secretKey ) :
# frpc.tomlserverAddr = "xxxx"serverPort = 7000[[visitors]]name = "secret_ssh_visitor"type = "stcp"serverName = "secret_ssh"secretKey = "abcdefg"bindAddr = "127.0.0.1"bindPort = 6000
Sur la machine C, connectez-vous en SSH sur la machine B, à l'aide de cette commande :
ssh -oPort=6000 127.0.0.1
xtcp est conçu pour transmettre de grandes quantités de données directement entre clients. Un serveur frps est toujours nécessaire, car le P2P ne fait ici référence qu'à la transmission réelle des données.
Notez que cela peut ne pas fonctionner avec tous les types de périphériques NAT. Vous souhaiterez peut-être revenir à stcp si xtcp ne fonctionne pas.
Démarrez frpc sur la machine B et exposez le port SSH. Notez que le champ remotePort est supprimé :
# frpc.tomlserverAddr = "xxxx"serverPort = 7000# configurer un nouveau serveur par défaut si celui par défaut n'est pas disponible.# natHoleStunServer = "xxx"[[proxies]]name = "p2p_ssh"type = "xtcp"secretKey = " abcdefg"localIP = "127.0.0.1"localPort = 22
Démarrez un autre frpc (généralement sur une autre machine C) avec la configuration pour vous connecter à SSH en mode P2P :
# frpc.tomlserverAddr = "xxxx"serverPort = 7000# configurer un nouveau serveur par défaut si celui par défaut n'est pas disponible.# natHoleStunServer = "xxx"[[visitors]]name = "p2p_ssh_visitor"type = "xtcp"serverName = " p2p_ssh"secretKey = "abcdefg"bindAddr = "127.0.0.1"bindPort = 6000# lorsque la persistance automatique du tunnel est requise, définissez-le sur truekeepTunnelOpen = false
Sur la machine C, connectez-vous en SSH sur la machine B, à l'aide de cette commande :
ssh -oPort=6000 127.0.0.1
Depuis la version 0.52.0, nous prenons en charge TOML, YAML et JSON pour la configuration. Veuillez noter que INI est obsolète et sera supprimé dans les prochaines versions. Les nouvelles fonctionnalités ne seront disponibles qu'en TOML, YAML ou JSON. Les utilisateurs souhaitant ces nouvelles fonctionnalités doivent modifier leur format de configuration en conséquence.
Lisez les exemples complets de fichiers de configuration pour découvrir encore plus de fonctionnalités non décrites ici.
Les exemples utilisent le format TOML, mais vous pouvez toujours utiliser YAML ou JSON.
Ces fichiers de configuration sont uniquement à titre de référence. Veuillez ne pas utiliser cette configuration directement pour exécuter le programme car elle peut poser divers problèmes.
Fichier de configuration complet pour frps (serveur)
Fichier de configuration complet pour frpc (Client)
Les variables d'environnement peuvent être référencées dans le fichier de configuration, en utilisant le format standard 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 }}" Avec la configuration ci-dessus, les variables peuvent être transmises au programme frpc comme ceci :
export FRP_SERVER_ADDR=x.x.x.x export FRP_SSH_REMOTE_PORT=6000 ./frpc -c ./frpc.toml
frpc affichera le modèle de fichier de configuration à l'aide des variables d'environnement du système d'exploitation. N'oubliez pas de préfixer votre référence avec .Envs .
Vous pouvez diviser plusieurs configurations de proxy en différents fichiers et les inclure dans le fichier principal.
# frpc.tomlserverAddr = "xxxx"serverPort = 7000includes = ["./confd/*.toml"]
# ./confd/test.toml[[proxies]]name = "ssh"type = "tcp"localIP = "127.0.0.1"localPort = 22remotePort = 6000
Vérifiez le statut du frp et les informations statistiques des proxys via le tableau de bord.
Configurez un port pour le tableau de bord pour activer cette fonctionnalité :
# La valeur par défaut est 127.0.0.1. Remplacez-le par 0.0.0.0 lorsque vous souhaitez y accéder depuis un réseau public.webServer.addr = "0.0.0.0"webServer.port = 7500# Le nom d'utilisateur et le mot de passe du tableau de bord sont tous deux facultatifswebServer.user = "admin"webServer.password = " administrateur"
Visitez ensuite http://[serverAddr]:7500 pour voir le tableau de bord, avec le nom d'utilisateur et le mot de passe étant tous deux admin .
De plus, vous pouvez utiliser le port HTTPS en utilisant le caractère générique de votre domaine ou le certificat SSL normal :
webServer.port = 7500# le nom d'utilisateur et le mot de passe du tableau de bord sont tous deux facultatifswebServer.user = "admin"webServer.password = "admin"webServer.tls.certFile = "server.crt"webServer.tls.keyFile = "server.key"
Visitez ensuite https://[serverAddr]:7500 pour voir le tableau de bord en connexion HTTPS sécurisée, avec le nom d'utilisateur et le mot de passe étant tous deux admin .
L'interface utilisateur d'administration client vous aide à vérifier et à gérer la configuration de frpc.
Configurez une adresse pour l'interface utilisateur d'administration pour activer cette fonctionnalité :
webServer.addr = "127.0.0.1" webServer.port = 7400webServer.user = "admin" webServer.password = "admin"
Visitez ensuite http://127.0.0.1:7400 pour voir l'interface utilisateur de l'administrateur, le nom d'utilisateur et le mot de passe étant tous deux admin .
Lorsque le serveur Web est activé, frps enregistre les données du moniteur dans le cache pendant 7 jours. Il sera effacé après le redémarrage du processus.
Prometheus est également pris en charge.
Activez d'abord le tableau de bord, puis configurez enablePrometheus = true dans frps.toml .
http://{dashboard_addr}/metrics fournira les données du moniteur Prometheus.
Il existe 2 méthodes d'authentification pour authentifier frpc avec frps.
Vous pouvez décider lequel utiliser en configurant auth.method dans frpc.toml et frps.toml , celui par défaut est token.
La configuration de auth.additionalScopes = ["HeartBeats"] utilisera la méthode d'authentification configurée pour ajouter et valider l'authentification à chaque battement de cœur entre frpc et frps.
La configuration de auth.additionalScopes = ["NewWorkConns"] fera de même pour chaque nouvelle connexion professionnelle entre frpc et frps.
Lorsque vous spécifiez auth.method = "token" dans frpc.toml et frps.toml , une authentification basée sur un jeton sera utilisée.
Assurez-vous de spécifier le même auth.token dans frps.toml et frpc.toml pour que frpc réussisse la validation frps
Lorsque vous spécifiez auth.method = "oidc" dans frpc.toml et frps.toml - l'authentification basée sur OIDC sera utilisée.
OIDC signifie OpenID Connect et le flux utilisé s'appelle Client Credentials Grant.
Pour utiliser ce type d'authentification, configurez frpc.toml et frps.toml comme suit :
# 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" # Remplacer par le client 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"
Les fonctionnalités sont désactivées par défaut. Vous pouvez activer le chiffrement et/ou la compression :
# frpc.toml[[proxies]]name = "ssh"type = "tcp"localPort = 22remotePort = 6000transport.useEncryption = truetransport.useCompression = true
Depuis la version 0.50.0, la valeur par défaut de transport.tls.enable et transport.tls.disableCustomTLSFirstByte a été modifiée en true et tls est activé par défaut.
Pour le multiplexage de port, frp envoie un premier octet 0x17 pour établir une connexion TLS. Cela ne prend effet que lorsque vous définissez transport.tls.disableCustomTLSFirstByte sur false.
Pour obliger frps à accepter uniquement les connexions TLS, configurez transport.tls.force = true dans frps.toml . Ceci est facultatif.
Paramètres TLS frpc :
transport.tls.enable = truetransport.tls.certFile = "certificate.crt" transport.tls.keyFile = "certificate.key" transport.tls.trustedCaFile = "ca.crt"
Paramètres TLS frps :
transport.tls.force = truetransport.tls.certFile = "certificate.crt" transport.tls.keyFile = "certificate.key" transport.tls.trustedCaFile = "ca.crt"
Vous aurez besoin d'un certificat CA racine et d'au moins un certificat SSL/TLS . Il peut être auto-signé ou régulier (comme Let's Encrypt ou un autre fournisseur de certificat SSL/TLS).
Si vous utilisez frp via une adresse IP et non un nom d'hôte, assurez-vous de définir l'adresse IP appropriée dans la zone Nom alternatif du sujet (SAN) lors de la génération de certificats SSL/TLS.
Étant donné un exemple :
Préparez le fichier de configuration openssl. Il existe dans /etc/pki/tls/openssl.cnf dans le système Linux et /System/Library/OpenSSL/openssl.cnf dans MacOS, et vous pouvez le copier dans le chemin actuel, comme cp /etc/pki/tls/openssl.cnf ./my-openssl.cnf . Sinon, vous pouvez le construire vous-même, comme :
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
créer des certificats 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
créer des certificats 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
créer des certificats 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
Les champs webServer sont requis pour activer l'API HTTP :
# frpc.tomlwebServer.addr = "127.0.0.1" webServer.port = 7400
Exécutez ensuite la commande frpc reload -c ./frpc.toml et attendez environ 10 secondes pour laisser frpc créer, mettre à jour ou supprimer des proxys.
Notez que les paramètres globaux du client ne seront pas modifiés sauf 'start'.
Vous pouvez exécuter la commande frpc verify -c ./frpc.toml avant de recharger pour vérifier s'il y a des erreurs de configuration.
Utilisez frpc status -c ./frpc.toml pour obtenir le statut de tous les proxys. Les champs webServer sont requis pour activer l'API HTTP.
allowPorts dans frps.toml est utilisé pour éviter les abus de ports :
# frps.tomlallowPorts = [
{ début = 2000, fin = 3000 },
{ unique = 3001 },
{ unique = 3003 },
{ début = 4000, fin = 50000 }
] vhostHTTPPort et vhostHTTPSPort dans frps peuvent utiliser le même port avec bindPort . frps détectera le protocole de connexion et le gérera en conséquence.
Ce à quoi vous devez faire attention, c'est que si vous souhaitez configurer vhostHTTPSPort et bindPort sur le même port, vous devez d'abord définir transport.tls.disableCustomTLSFirstByte sur false.
Nous aimerions essayer d'autoriser plusieurs proxys à lier un même port distant avec différents protocoles à l'avenir.
# frpc.toml[[proxies]]name = "ssh"type = "tcp"localPort = 22remotePort = 6000transport.bandwidthLimit = "1MB"
Définissez transport.bandwidthLimit dans la configuration de chaque proxy pour activer cette fonctionnalité. Les unités prises en charge sont MB et KB .
Définissez transport.bandwidthLimitMode sur client ou server pour limiter la bande passante côté client ou serveur. La valeur par défaut est client .
frp prend en charge le multiplexage de flux TCP depuis la version 0.10.0 comme le multiplexage HTTP2, auquel cas toutes les connexions logiques au même frpc sont multiplexées dans la même connexion TCP.
Vous pouvez désactiver cette fonctionnalité en modifiant frps.toml et frpc.toml :
# frps.toml et frpc.toml, doivent être sametransport.tcpMux = false
KCP est un protocole rapide et fiable qui peut obtenir l'effet de transmission d'une réduction de la latence moyenne de 30 à 40 % et une réduction du délai maximum d'un facteur trois, au prix de 10 à 20 % de bande passante gaspillée en plus. que TCP.
Le mode KCP utilise UDP comme transport sous-jacent. Utilisation de KCP dans frp :
Activez KCP en frps :
# frps.tomlbindPort = 7000# Spécifiez un port UDP pour KCP.kcpBindPort = 7000
Le numéro kcpBindPort peut être le même que bindPort , puisque le champ bindPort spécifie un port TCP.
Configurez frpc.toml pour utiliser KCP pour vous connecter à frps :
# frpc.tomlserverAddr = "xxxx"# Identique au 'kcpBindPort' dans frps.tomlserverPort = 7000transport.protocol = "kcp"
QUIC est un nouveau transport multiplexé construit sur UDP.
Utiliser QUIC dans frp :
Activer QUIC en frps :
# frps.tomlbindPort = 7000# Spécifiez un port UDP pour QUIC.quicBindPort = 7000
Le numéro quicBindPort peut être le même que bindPort , puisque le champ bindPort spécifie un port TCP.
Configurez frpc.toml pour utiliser QUIC pour vous connecter à frps :
# frpc.tomlserverAddr = "xxxx"# Identique au 'quicBindPort' dans frps.tomlserverPort = 7000transport.protocol = "quic"
Par défaut, frps crée une nouvelle connexion frpc au service backend à la demande de l'utilisateur. Avec le pooling de connexions, frps conserve un certain nombre de connexions préétablies, réduisant ainsi le temps nécessaire à l'établissement d'une connexion.
Cette fonctionnalité convient à un grand nombre de connexions courtes.
Configurez la limite du nombre de pools que chaque proxy peut utiliser dans frps.toml :
# frps.tomltransport.maxPoolCount = 5
Activez et précisez le nombre de pool de connexions :
# frpc.tomltransport.poolCount = 1
L'équilibrage de charge est pris en charge par group .
Cette fonctionnalité n'est désormais disponible que pour les types 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 est utilisé pour l'authentification.
Les connexions au port 80 seront distribuées aléatoirement aux proxys du même groupe.
Pour le type tcp , remotePort du même groupe doit être le même.
Pour le type http , customDomains , subdomain , locations doivent être les mêmes.
La fonction de vérification de l'état peut vous aider à atteindre une haute disponibilité avec l'équilibrage de charge.
Ajoutez healthCheck.type = "tcp" ou healthCheck.type = "http" pour activer la vérification de l'état.
Avec le type de contrôle de santé tcp , le port de service sera pingé (TCPing) :
# frpc.toml[[proxies]]name = "test1"type = "tcp"localPort = 22remotePort = 6000# Activer la vérification de l'état TCPhealthCheck.type = "tcp"# Délai d'expiration TCPing secondshealthCheck.timeoutSeconds = 3# Si la vérification de l'état a échoué 3 fois d'affilée, le proxy sera supprimé de frpshealthCheck.maxFailed = 3# Un bilan de santé toutes les 10 secondeshealthCheck.intervalSeconds = 10
Avec un contrôle de santé de type http , une requête HTTP sera envoyée au service et une réponse HTTP 2xx OK est attendue :
# frpc.toml[[proxies]]name = "web"type = "http"localIP = "127.0.0.1"localPort = 80customDomains = ["test.example.com"]# Activer le contrôle de santé HTTPhealthCheck.type = "http" # frpc enverra une requête GET à '/status'# et attendra un HTTP 2xx OK réponsehealthCheck.path = "/status"healthCheck.timeoutSeconds = 3healthCheck.maxFailed = 3healthCheck.intervalSeconds = 10
Par défaut, frp ne modifie pas du tout les requêtes HTTP tunnelisées car il s'agit d'une copie octet par octet.
Cependant, en parlant de serveurs Web et de requêtes HTTP, votre serveur Web peut s'appuyer sur l'en-tête HTTP Host pour déterminer le site Web auquel accéder. frp peut réécrire l'en-tête Host lors du transfert des requêtes HTTP, avec le champ hostHeaderRewrite :
# frpc.toml[[proxies]]name = "web"type = "http"localPort = 80customDomains = ["test.example.com"]hostHeaderRewrite = "dev.example.com"
L'en-tête Host de la requête HTTP sera réécrit en Host: dev.example.com lorsqu'elle atteindra le serveur Web réel, bien que la requête du navigateur ait probablement Host: test.example.com .
Semblable à Host , Vous pouvez remplacer d'autres en-têtes de requête et de réponse HTTP par le type 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 = "bar"
Dans cet exemple, il définira l'en-tête x-from-where: frp dans la requête HTTP et foo: bar dans la réponse HTTP.
Cette fonctionnalité est destinée aux proxys http ou aux proxys avec les plugins https2http et https2https activés.
Vous pouvez obtenir la véritable adresse IP de l'utilisateur à partir des en-têtes de requête HTTP X-Forwarded-For .
frp prend en charge le protocole proxy pour envoyer la véritable adresse IP de l'utilisateur aux services locaux. Il prend en charge tous les types sauf UDP.
Voici un exemple de service https :
# frpc.toml[[proxies]]name = "web"type = "https"localPort = 443customDomains = ["test.example.com"]# maintenant les versions 1 et 2 sont prises en chargetransport.proxyProtocolVersion = "v2"
Vous pouvez activer la prise en charge du protocole proxy dans nginx pour exposer la véritable adresse IP de l'utilisateur dans l'en-tête HTTP X-Real-IP , puis lire l'en-tête X-Real-IP dans votre service Web pour la véritable adresse IP.
Toute personne capable de deviner l'URL de votre tunnel peut accéder à votre serveur Web local à moins que vous ne le protégiez avec un mot de passe.
Cela applique l'authentification HTTP Basic à toutes les demandes avec le nom d'utilisateur et le mot de passe spécifiés dans le fichier de configuration de frpc.
Il ne peut être activé que lorsque le type de proxy est http.
# frpc.toml[[proxies]]name = "web"type = "http"localPort = 80customDomains = ["test.example.com"]httpUser = "abc"httpPassword = "abc"
Visitez http://test.example.com dans le navigateur et vous êtes maintenant invité à saisir le nom d'utilisateur et le mot de passe.
Il est pratique d'utiliser la configuration subdomain pour les types http et https lorsque de nombreuses personnes partagent un serveur frps.
# frps.tomlsubDomainHost = "frps.com"
Résolvez *.frps.com en l'adresse IP du serveur frps. C'est ce qu'on appelle généralement un enregistrement DNS Wildcard.
# frpc.toml[[proxies]]name = "web"type = "http"localPort = 80subdomain = "test"
Vous pouvez désormais visiter votre service web sur test.frps.com .
Notez que si subdomainHost n'est pas vide, customDomains ne doit pas être le sous-domaine de subdomainHost .
frp prend en charge le transfert des requêtes HTTP vers différents services Web backend par routage d'URL.
locations spécifie le préfixe de l'URL utilisé pour le routage. frps recherche d'abord l'emplacement de préfixe le plus spécifique donné par les chaînes littérales, quel que soit l'ordre indiqué.
# frpc.toml[[proxies]]name = "web01"type = "http"localPort = 80customDomains = ["web.example.com"]locations = ["/"] [[proxies]]name = "web02"type = "http"localPort = 81customDomains = ["web.example.com"]locations = ["/news", "/about"]
Les requêtes HTTP avec le préfixe URL /news ou /about seront transmises à web02 et les autres requêtes à web01 .
frp prend en charge la réception de sockets TCP dirigés vers différents proxys sur un seul port sur frps, similaire à vhostHTTPPort et vhostHTTPSPort .
La seule méthode de multiplexage de port TCP prise en charge disponible pour le moment est httpconnect - HTTP CONNECT tunnel.
Lorsque vous définissez tcpmuxHTTPConnectPort sur autre chose que 0 dans frps, frps écoutera sur ce port les requêtes HTTP CONNECT.
L'hôte de la requête HTTP CONNECT sera utilisé pour faire correspondre le proxy en frps. Les hôtes proxy peuvent être configurés dans frpc en configurant customDomains et/ou subdomain sous les proxys tcpmux , lorsque multiplexer = "httpconnect" .
Par exemple:
# 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
Dans la configuration ci-dessus, frps peut être contacté sur le port 1337 avec un en-tête HTTP CONNECT tel que :
CONNECT test1 HTTP/1.1rnrn
et la connexion sera acheminée vers proxy1 .
frpc peut se connecter à frps via un proxy si vous définissez la variable d'environnement du système d'exploitation HTTP_PROXY ou si transport.proxyURL est défini dans le fichier frpc.toml.
Cela ne fonctionne que lorsque le protocole est TCP.
# frpc.tomlserverAddr = "xxxx"serverPort = 7000transport.proxyURL = "http://user:[email protected]:8080"
Ajouté dans la v0.56.0
Nous pouvons utiliser la syntaxe de plage du modèle Go combinée à la fonction parseNumberRangePair intégrée pour réaliser le mappage de plage de ports.
L'exemple suivant, une fois exécuté, créera 8 proxys nommés test-6000, test-6001 ... test-6007 , chacun mappant le port distant au port 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 transmet uniquement les requêtes aux ports TCP ou UDP locaux par défaut.
Les plugins sont utilisés pour fournir des fonctionnalités riches. Il existe des plugins intégrés tels que unix_domain_socket , http_proxy , socks5 , static_file , http2https , https2http , https2https et vous pouvez voir des exemples d'utilisation.
Utilisation du plugin http_proxy :
# frpc.toml[[proxies]]name = "http_proxy"type = "tcp"remotePort = 6000[proxies.plugin]type = "http_proxy"httpUser = "abc"httpPassword = "abc"
httpUser et httpPassword sont des paramètres de configuration utilisés dans le plugin http_proxy .
Lisez le document.
Trouvez plus de plugins dans gofrp/plugin.
ajouté dans la v0.53.0
frp prend en charge l'écoute d'un port SSH du côté frps et réalise le proxy du protocole TCP via le protocole SSH -R, sans compter sur frpc.
# frps.tomlsshTunnelGateway.bindPort = 2200
Lors de l'exécution ./frps -c frps.toml , un fichier de clé privée nommé .autogen_ssh_key sera automatiquement créé dans le répertoire de travail actuel. Ce fichier de clé privée généré sera utilisé par le serveur SSH en frps.
Exécuter la commande
ssh -R :80:127.0.0.1:8080 v0@{adresse frp} -p 2200 tcp --proxy_name "test-tcp" --remote_port 9090configure un proxy sur frps qui transmet le service 8080 local au port 9090.
frp (via SSH) (Ctrl+C pour quitter) Utilisateur: Nom du proxy : test-tcp Tapez : tcp Adresse distante : 9090
Cela équivaut à :
frpc tcp --proxy_name "test-tcp" --local_ip 127.0.0.1 --local_port 8080 --remote_port 9090
Veuillez vous référer à ce document pour plus d'informations.
gofrp/plugin - Un référentiel de plugins frp qui contient une variété de plugins implémentés sur la base du mécanisme d'extension frp, répondant aux besoins de personnalisation de différents scénarios.
gofrp/tiny-frpc - Une version allégée du client frp (environ 3,5 Mo au minimum) implémentée à l'aide du protocole ssh, prenant en charge certaines des fonctionnalités les plus couramment utilisées, adaptée aux appareils aux ressources limitées.
Vous souhaitez vous impliquer ? Nous aimerions vous aider!
Jetez un œil à notre liste de problèmes et envisagez d'envoyer une Pull Request à la branche dev .
Si vous souhaitez ajouter une nouvelle fonctionnalité, veuillez d'abord créer un problème pour décrire la nouvelle fonctionnalité, ainsi que l'approche de mise en œuvre. Une fois qu'une proposition est acceptée, créez une implémentation des nouvelles fonctionnalités et soumettez-la sous forme de pull request.
Désolé pour mon mauvais anglais. Les améliorations de ce document sont les bienvenues, même quelques corrections de fautes de frappe.
Si vous avez de bonnes idées, envoyez un email à [email protected].
Remarque : Nous préférons que vous donniez votre avis sur les problèmes, afin que d'autres personnes ayant la même question puissent la rechercher rapidement et que nous n'ayons pas besoin d'y répondre à plusieurs reprises.
Si frp vous aide beaucoup, vous pouvez nous soutenir en :
Soutenez-nous par les sponsors Github.
Vous pouvez placer le logo de votre entreprise sur le fichier README de ce projet.
Faites un don par PayPal sur mon compte [email protected] .
