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ù on est présent et confirme une panne depuis deux autres continents avant de réveiller quelqu'un, ce qu'un simple test ne peut pas te 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 vérification ici, elle s'exécute depuis Amsterdam, New York, Sydney and Singapore, et un échec est confirmé depuis deux autres continents avant que quelqu'un soit réveillé. 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 contrôle parfaitement valable et qui 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 peut échouer sans te prévenir. Une connexion qui échoue depuis un endroit ne distingue pas un service arrêté d'une route cassée, ce que deux autres continents clarifient avant que quelqu'un soit appelé.