Atteindre les services locaux

Interrogez un service qui n'écoute que sur votre serveur — Prometheus, une API d'admin, un healthcheck — sans ouvrir de port ni monter de tunnel SSH. L'agent fait la requête depuis l'intérieur de la machine.

Beaucoup de choses utiles sur un serveur n'écoutent que sur 127.0.0.1 : les métriques Prometheus sur :9090, l'API d'admin d'un service sur :8080, un healthcheck applicatif sur :3000. C'est le bon réflexe — rien de tout ça n'a à être exposé sur Internet. Mais il faut quand même pouvoir les lire.

La réponse habituelle est ssh -L 9090:localhost:9090. Servor fait la même chose autrement : l'agent effectue la requête depuis l'intérieur de la machine et vous en renvoie la réponse. Le service reste sur 127.0.0.1, aucun port n'est ouvert, aucun tunnel SSH n'est monté.

Interroger un service

Ouvrir la surveillance du serveur

Allez dans Serveurs, sélectionnez la machine, puis le panneau Services locaux. Votre coffre doit être déverrouillé — la requête est signée par votre navigateur, comme une commande.

Choisir la cible

Les ports en écoute locale détectés sur la machine sont proposés en un clic, avec le processus qui les tient. Ce sont exactement ceux que rien ne peut atteindre depuis l'extérieur. Vous pouvez aussi saisir l'hôte et le port à la main.

Composer la requête

Méthode (GET, POST, PUT, PATCH, DELETE, HEAD), chemin, en-têtes et corps si la méthode en accepte un. Un en-tête Authorization est saisi masqué et n'est jamais journalisé, ni par l'API ni par l'agent.

Lire la réponse

Statut, durée, en-têtes et corps. Le corps est affiché comme du texte, jamais rendu comme une page : ce que sert un port local n'a pas à s'exécuter dans votre dashboard.

Ce que ça n'est pas

C'est une requête, pas une redirection de port. Il n'y a pas de socket local ouvert sur votre machine : un navigateur ne peut pas en ouvrir. Vous ne pouvez donc pas y brancher psql ou redis-cli, ni afficher l'interface web d'un service comme si vous y naviguiez. Pour ça, le terminal web reste l'outil : il vous donne un shell là où le service est joignable.

Ce que vous obtenez, c'est la lecture directe de tout ce qui parle HTTP : métriques, santé, statut, API d'administration.

Limites

HTTP et HTTPS uniquement.
1 Mo de réponse au maximum ; au-delà, elle est tronquée et le panneau le dit.
256 Ko de corps de requête au maximum.
15 secondes avant abandon.
Les redirections ne sont pas suivies : une redirection suivie en silence vous ferait lire une autre URL que celle que vous avez signée.

En HTTPS, un service local présente souvent un certificat auto-signé. Une option Ne pas vérifier le certificat existe pour ce cas ; ce choix fait partie de ce que votre navigateur signe, il ne peut donc pas être activé à votre place en cours de route.

Sécurité

La requête est signée par votre navigateur : la méthode, l'hôte, le port, le chemin, les en-têtes et l'empreinte du corps sont couverts. Une approbation pour GET /metrics ne peut pas être rejouée en DELETE, et un relais ne peut pas modifier un en-tête en gardant la signature valide.
L'agent la vérifie localement avant d'agir. Les serveurs de Servor ne peuvent pas en forger une.
Rien du contenu n'est journalisé. Le journal d'audit garde la cible (méthode, hôte, port, chemin) et le code de statut ; jamais les en-têtes ni les corps.
Rôle membre minimum, comme pour exécuter une commande — un lecteur ne peut pas. C'est cohérent : qui peut ouvrir un shell sur la machine peut déjà y faire un curl.
Le mode strict ferme aussi ce chemin, comme il ferme l'exécution.

Voir aussi

Terminal webUn shell complet quand une requête ne suffit pas.Exécuter des commandesPremier plan, arrière-plan et historique.Rôles et permissionsQui peut faire quoi.Parcourir les fichiersL'autre chemin signé vers la machine.