TCP port
Surveillance de port TCP
N'importe quel hôte, n'importe quel port, et ce qu'il dit quand il répond.
Essaie-le maintenant
Un test, depuis un endroit, tout de suite, et rien n'est sauvegardé. Un monitor vérifie depuis chaque emplacement où nous sommes présents et confirme une panne depuis trois continents avant de réveiller quelqu'un, ce qu'un simple test ne peut pas montrer.
À quoi ça sert
Le contrôle pour un service qui n'est pas un site web. Une base de données, un serveur de jeu, un point de terminaison VPN, SSH : des choses qui écoutent sur un port sans HTTP à interroger ni page à lire.
On ouvre le port, et le contrôle peut aussi exiger le message d'accueil attendu du service. Un port qui accepte une connexion mais ne dit rien ressemble à un service à moitié mort vu de l'extérieur, et un simple contrôle de port ouvert considère cela comme sain.
Comme chaque test ici, il s'exécute depuis Amsterdam, New York, Sydney and Singapore, et une panne est confirmée depuis trois continents avant de réveiller quelqu'un. Comment ça marche.
Ce que tu peux configurer
Tout ce qui suit est dans le formulaire quand tu en ajoutes un, sur chaque forfait.
- Hôte et port
- Un nom d'hôte ou une adresse et un port, car il n'y a pas de port par défaut logique à deviner.
- Salutation attendue
- Une expression régulière que le premier message du service doit correspondre.
Questions
Quels ports valent la peine d'être surveillés avec un contrôle TCP ?
Le port 22 pour SSH, 3306 pour MySQL, 5432 pour PostgreSQL, 6379 pour Redis, et tout autre port sur lequel ton service écoute. Il n'y a pas de port par défaut, car un port deviné est un monitor qui surveille quelque chose que tu n'as pas demandé, donc le port fait partie de ce que tu saisis.
À quoi sert le message d'accueil attendu ?
Il lit les premiers octets envoyés par le service et les compare à une expression régulière que tu donnes, ce qui correspond à un banner grab. Sans cela, c'est un simple contrôle de port ouvert, et un contrôle de port ouvert considère un service à moitié ouvert comme sain : le port accepte ta connexion mais ce qu'il y a derrière ne dit jamais un mot.
Connexion refusée, ou un timeout ?
Refusé signifie que l'hôte a répondu et t'a dit que rien n'écoute là, ce qui est généralement un service arrêté plutôt qu'une machine éteinte. Un timeout signifie que rien n'est revenu, ce qui peut être un pare-feu qui bloque les paquets, un hôte injoignable ou un réseau entre les deux. Ils sont signalés séparément pour cette raison.
Peux-tu vérifier un port UDP ?
Non, et on le dit plutôt que de proposer quelque chose qui y ressemble. Un port UDP ouvert et un port UDP filtré sont indiscernables de l'extérieur sauf si le service choisit de répondre, donc un contrôle de port UDP est une supposition déguisée en statut. Surveille le service autrement.
Pourquoi ne pas utiliser netcat sur le port depuis un script ?
Pour un port sur un hôte où tu as déjà une machine à côté, c'est un test parfaitement valable et ça tient en une ligne. Le problème est le même qu'ailleurs ici : le script s'exécute quelque part, et ce quelque part est une chose qui peut tomber en panne sans te prévenir. Une connexion qui échoue depuis un seul endroit ne distingue pas un service arrêté d'une route cassée, ce que trois continents clarifient avant que quelqu'un soit appelé.