Problèmes de connexion de la passerelle

La passerelle n'est pas considérée comme connectée par la plate-forme

SYMPTÔME : La passerelle est en marche, mais elle n'est pas vue comme connectée par la plate-forme. L'état de la passerelle reste en "Initialisation" ou "Erreur de connexion" dans l'interface graphique de TPE.

SOLUTION : Consultez les différentes approches de dépannage décrites ci-dessous.

Dépanner depuis Cockpit

1. Vérifiez que le certificat IPsec pour la passerelle n'est pas expiré.

2. Si le certificat IPsec a expiré, un message d'erreur s'affiche en haut de la page "Configuration TPE" :

   

3. Dans ce cas, vous devez générer un nouveau certificat et le télécharger. Consultez la procédure décrite dans l'Annexe Generation du certificat IPsec pour le trafic des passerelles du Guide d'installation et de configuration de ThingPark Enterprise.

AVERTISSEMENT

Lorsque le certificat est changé, toutes les passerelles seront temporairement déconnectées pour récupérer le nouveau certificat. Ce nouveau certificat doit être régénéré manuellement pour toutes les passerelles déjà créées. Pour ce faire, suivez la procédure décrite Régénérer les certificats IPsec pour le trafic des passerelles.

Dépanner depuis la passerelle via le menu Suplog

1. Tester la connectivité avec LRC

Tester la connectivité avec LRC via le menu "Dépannage/Pings LRCs" :

Si le ping échoue, vous devez tester vos tunnels IPSEC et la connectivité avec votre IP PKI. Pour plus d'informations, voir Tester la connectivité avec PKI et Tester le statut IPSec avec le serveur TPE.

2. Tester la connectivité avec PKI

Tester la connectivité avec PKI via le menu "Dépannage/Ping" (saisir l'IP du serveur PKI):

Si le ping échoue, vérifiez votre réseau interne (pare-feu, flux IP).

3. Tester le statut IPSec avec le serveur TPE

Tester le statut IPSec avec le serveur TPE via le menu "Configuration VPN/Afficher le statut IPSec" (non applicable pour BS sans IPSec):

Si vous pouvez voir "lrc1[1]: ÉTABLI", alors le statut IPSec est OK.

Sinon, vous devez tester si les certificats sont correctement installés (voir Tester si les certificats sont installés et valides).

4. Vérifier si les certificats sont installés et valides

Tester si les certificats sont installés et valides via le menu "Configuration VPN/Afficher la liste des certificats IPSec" (non applicable pour BS sans IPSec) :

• Vérifiez votre UUID dans le nom du sujet.
• Vérifiez la date de validité ("expire dans XX jours").
• Si vous ne voyez aucune sortie, les certificats n'ont pas été installés. Vous devez vérifier la disponibilité des certificats depuis le support docker (voir Tester si les certificats BS sont disponibles au téléchargement).

5. Tester si les processus obligatoires fonctionnent

Tester si les processus obligatoires fonctionnent via le menu "Dépannage/CPU/Mémoire/Processus" :

L'application "lrr.x" est obligatoire (essayez éventuellement de redémarrer la passerelle si vous ne l'avez pas).

Les processus "Charon" et "checkvpn.sh" devraient fonctionner sur la passerelle utilisant IPSEC, si "charon"/ipsec ne fonctionne pas, vous devez vérifier la disponibilité des certificats depuis le support docker (voir Tester si les certificats BS sont disponibles au téléchargement).

Dépanner depuis le support

Tester si les certificats BS sont disponibles au téléchargement

Les certificats sont stockés dans la base de données Mongo.

Depuis le nœud1, connectez-vous à Mongo db :

source /etc/thingpark/tpe/installer-release ; docker run -it --rm --network=actility_tpeha-network  --entrypoint="" tpe:${tpeInstallerRelease}  mongosh --username admin --password --authenticationDatabase admin --host mongo_node1 --port 27017

Sélectionnez la base de données "key-installer" :

rs0:PRIMARY> use key-installer
switched to db key-installer

Dans la collection "archives", vérifiez la disponibilité du paquet de certificat basé sur votre LRR UUID.

Exemple ci-dessous avec LRR UID "123456-46584254C0001340".

rs0:PRIMARY> db.archives.find({"lrrUUID": "123456-46584254C0001340"});

Si le paquet de certificats n'a pas été créé, essayez de régénérer le certificat à partir du GUI TPE.

Dépanner depuis SLRC

Tester le statut IPSec du côté serveur

1. Journal IPSec :

   docker logs tpe-slrc

2. Connectez-vous à l'intérieur du docker slrc :

   docker exec -it tpe-slrc bash

3. Vérifiez le statut IPSec :

   ipsec statusall

Dépanner depuis LRC

Tester la connexion de la passerelle depuis le côté serveur

1. Connectez-vous à l'intérieur du docker lrc :

   docker exec -it $(docker ps -q -f "name=actility_lrc1") bash

2. Connectez-vous à l'interface CLI LRC via telnet (login : support, mot de passe : support) :

   telnet 0 2009

3. Vérifiez toutes les passerelles actuellement connectées au LRC :

   >> ls

4. Vérifiez une connexion de la passerelle en fonction de son LRR UUID :

   >> ls <LRR UUID>

Dépanner depuis RCA

Tester la configuration PKI

1. Connectez-vous à l'intérieur du docker rca :

   docker exec -it $(docker ps -q -f "name=actility_rca") bash

2. Vérifiez que votre IP PKI est correcte pour la configuration ipsec :

   cat /opt/ejbca/conf/actility-ope/ipsec.conf | grep "right="

Dépanner depuis l'interface TPE

Tester le statut de connexion rapporté par l'interface

Lorsque le VPN et les flux entre le BS et le TPE sont tous OK, l'état du BS passera de "Initialisation" à "Erreur de connexion" pendant environ 10 à 15 minutes lors de la première connexion.

Lorsque le TPE reçoit le premier rapport de la passerelle, le statut deviendra "Actif".

• Si la passerelle a été supprimée et recréée dans TPE, l'état "Initialisation" peut persister. Dans ce cas, la passerelle doit être réinitialisée.
• Pour les BS non connectés avec IPSec, l'état "Erreur de connexion" peut persister. Dans ce cas, vous devez vous connecter au BS et mettre à jour la configuration lrr avec l'IP (X.X.X.X) de l'instance TPE au lieu du nom d'hôte (hostname.domain).

La passerelle n'est pas en mesure d'établir une connexion

SYMPTÔME : Après une mise à niveau, les passerelles ne sont plus capables de récupérer la RFRegion, de télécharger un scan radio ou d'établir une connexion à distance.

SOLUTION :

Réinitialiser le fichier known_hosts sur toutes les passerelles connectées (La mise à jour vers certaines versions 7.1 peut entraîner la génération de nouvelles clés hôtes SSH et perturber les services SSH):

1. Exécutez une commande ssh pour se connecter au nœud TPE :

   ssh support@${IP_OR_HOSTNAME_OF_TPE} -p 2222

2. Ensuite, exécutez le script suivant pour réinitialiser le fichier known_hosts :

   /usr/bin/tpe-remove-bs-known-hosts-file