Guide des ports FRP : tunnels proxy inverse sur le port 7000

FRP a un côté serveur appelé frps et un côté client appelé frpc. frps s'exécute sur une machine avec une adresse publique accessible. frpc s'exécute à proximité du service privé, se connecte vers l'extérieur à frps, s'authentifie et demande à frps d'exposer un service local via un proxy configuré.

Ce modèle est utile lorsqu'un laboratoire à domicile, une succursale, un appareil, un environnement de test ou un service de réseau privé a besoin d'un accès externe temporaire ou contrôlé. Cela signifie également que frps devient une périphérie connectée à Internet, de sorte que les jetons, TLS, ACL, les journaux et la portée des services sont aussi importants que le port lui-même.

TCP 7000 est couramment utilisé comme frps bind_port, où frpc établit la connexion de contrôle. Le mode proxy inverse HTTP et HTTPS peut utiliser vhost_http_port et vhost_https_port, souvent 80 et 443. Les mappages de proxy TCP et UDP peuvent exposer des ports distants personnalisés auxquels les utilisateurs se connectent directement.

FRP peut également exposer un tableau de bord, un point de terminaison de métriques ou une interface d'administration en fonction de la configuration. Ces ports de gestion ne doivent pas être traités comme des ports d’application publics. Limitez-les aux adresses IP de confiance, aux VPN, aux hôtes locaux ou aux réseaux privés.

Ouvrez le port de liaison frps lorsque des clients frpc de confiance doivent enregistrer des tunnels à partir de réseaux privés. Ouvrez les ports distants destinés aux utilisateurs uniquement pour les services que vous publiez intentionnellement, tels qu'un aperçu d'une application Web, un accès SSH via un tunnel contrôlé, un récepteur webhook ou un serveur de jeu.

N'exposez pas de larges plages de ports ou d'interfaces de gestion simplement parce que FRP facilite les choses. Chaque port distant est un point d'entrée public vers quelque chose derrière le tunnel, et chaque mappage doit avoir un propriétaire, un objectif, une politique d'accès et une date de suppression s'il est temporaire.

Avant d'autoriser le port 7000, décidez quels clients peuvent se connecter, quels types de proxy sont autorisés, quels ports distants peuvent être enregistrés et si le trafic doit utiliser TLS. Vérifiez les jetons d'authentification ou les paramètres OIDC, la dénomination du client et vérifiez si l'élévation des privilèges via des ports distants arbitraires est possible.

Un vérificateur de port peut confirmer si le port de liaison frps ou un port distant publié est accessible, mais il ne peut pas prouver que l'authentification FRP, la propriété de la route ou la sécurité du service backend sont correctes. Validez à la fois le chemin de contrôle du tunnel et le comportement de l’application exposée.

Sur un serveur cloud, exécutez frps avec une adresse IP publique fixe ou un nom DNS stable, autorisez uniquement le port de liaison requis et les ports de service publiés, et gardez l'accès au tableau de bord ou à l'administrateur privé. Placez le trafic HTTP et HTTPS derrière le TLS normal et le routage basé sur l'hôte lorsque cela est possible.

Sur les clients Linux ou Windows, exécutez frpc en tant que service à proximité de l'application privée. Configurez soigneusement local_ip, local_port, le type de proxy, le port_distant ou le domaine personnalisé et les informations d'identification. Évitez de réutiliser le même jeton dans des environnements non liés.

Si FRP est utilisé pour un accès de type production, ajoutez la supervision des processus, la conservation des journaux, la surveillance, le renouvellement des certificats et le contrôle des modifications. Un tunnel qui commence par commodité peut devenir une infrastructure critique plus rapidement que prévu.

Commencez par une vérification du port externe par rapport au nom d'hôte ou à l'adresse IP publique du frps et au port 7000. S'il est ouvert, les clients frpc pourront peut-être atteindre l'écouteur de contrôle. Vérifiez ensuite les journaux frps et frpc pour confirmer l'authentification, l'enregistrement du proxy et l'état du battement de cœur.

Ensuite, testez le service publié lui-même. Pour les tunnels HTTP ou HTTPS, utilisez curl ou un navigateur sur le domaine public. Pour les tunnels TCP, connectez-vous au port distant configuré avec le client réel. Un port de contrôle sain ne garantit pas que l'application backend ou le mappage des ports distants fonctionnent.

Si le port 7000 est fermé, frps peut ne pas être en cours d'exécution, peut être lié à localhost ou peut être bloqué par le pare-feu de l'hôte ou le groupe de sécurité cloud. Si frpc ne peut pas se connecter, vérifiez également DNS, server_addr, bind_port, les paramètres TLS, la non-concordance des jetons et les règles de sortie réseau côté client.

Si la connexion de contrôle fonctionne mais que le service est inaccessible, inspectez les conflits de ports distants, le routage du domaine vhost, les en-têtes d'hôte HTTP, les écouteurs de service locaux, le NAT du côté frpc et la politique frps allow_ports. De nombreux problèmes FRP surviennent après l’enregistrement du tunnel, et non lors de la vérification initiale du port.

Traitez frps comme une passerelle publique. Utilisez une authentification forte, faites pivoter les jetons, restreignez les ports autorisés, désactivez les types de proxy inutilisés, protégez les tableaux de bord et enregistrez les connexions client et les enregistrements de proxy. N'exposez pas les outils d'administration internes via FRP sans couche d'authentification supplémentaire.

Pour les services sensibles, placez FRP derrière un VPN, un proxy prenant en compte l'identité, mTLS, une liste blanche de pare-feu ou un proxy inverse avec limitation de débit. Examinez régulièrement les tunnels actifs et supprimez les mappages qui n'ont plus de propriétaire ou d'objectif commercial clair.