Aller au contenu principal

Dépannage réseau

Les problèmes ci-dessous ont déjà été rencontrés lors de la mise en place de nos sites. Commence toujours par identifier quelle pièce ne répond pas : le DNS, Caddy ou le service.

Isoler le problème​

Depuis un poste admin :

nslookup project.formuleets.ca 1.1.1.1

La réponse doit être 142.137.247.115. Sinon, c'est le DNS.

curl -I http://10.194.24.48:8080
curl -I --resolve project.formuleets.ca:443:142.137.247.115 https://project.formuleets.ca
  • La première échoue : le service est arrêté ou un pare-feu bloque la machine.
  • La première marche, pas la deuxième : c'est le domaine ou le manipulateur dans Caddy.
  • Les deux marchent, mais pas le nom dans le navigateur : c'est le DNS ou le cache du navigateur.

Erreur 502 Bad Gateway​

Caddy reçoit bien la requête mais n'arrive pas à joindre le service.

  1. Le service démarre encore. Après un docker compose up -d, OpenProject met 1 à 3 minutes. Après un gitlab-ctl reconfigure, GitLab répond 502 pendant environ une minute. Vérifie avec docker compose ps et docker compose logs -f --tail=50.
  2. Le service ne répond pas. Ouvre http://IP:PORT directement. S'il ne répond pas, le problème est sur la machine du service.
  3. Un pare-feu bloque. Les requêtes de Caddy viennent d'OPNsense : 10.194.24.56 pour les machines du réseau de l'école, 192.168.1.1 pour celles du LAN d'OPNsense (GitLab). Sur la machine du service, vérifie sudo ufw status.
  4. Mauvais réglages du manipulateur. Vérifie le Protocole amont (http://), le Domaine amont (dans une pastille) et le Port amont, puis que tu as bien cliqué sur Appliquer.
GitLab Pages répond 502 juste après un redémarrage de GitLab

Pages demande à GitLab la liste des sites, en passant par Caddy. Si GitLab ne répondait pas encore, Pages garde l'erreur en cache 1 à 2 minutes. Attends un peu avant de chercher plus loin.

Redirection en boucle ou « Invalid host_name »​

Le service ne reconnaît pas le nom de domaine. C'est ce qui arrivait avec OpenProject quand OPENPROJECT_HOST__NAME valait encore 10.194.24.48:8080.

Corrige la variable de nom d'hôte du service (voir Ajouter un sous-domaine), puis recrée les conteneurs avec docker compose down et docker compose up -d.

Une boucle peut aussi venir du service qui redirige lui-même vers HTTPS alors que Caddy lui parle en HTTP. Le service doit accepter le HTTP venant de Caddy et laisser Caddy gérer le HTTPS.

Le certificat n'est pas obtenu​

Si Caddy présente un certificat invalide ou aucun certificat pour un nom, regarde son journal dans OPNsense (menu Services → Caddy Web Server) et cherche les lignes qui contiennent acme, certificate ou challenge.

Ce que tu voisCauseSolution
timed out waiting for record to fully propagateLe résolveur utilisé ne voit pas encore l'enregistrement TXTVérifie Résolveurs = 1.1.1.1 dans l'onglet Fournisseur de DNS
Invalid API token, code 6003 ou 403Jeton Cloudflare mal copié, révoqué ou sans le droit DNS EditRecolle le jeton (voir Remplacer le jeton)
Rien à propos du domaineDéfi DNS-01 pas coché, ou Appliquer oubliéCorrige le domaine, puis Appliquer
À compléter

Le nom exact du menu des journaux de Caddy dans OPNsense, à vérifier lors d'une prochaine intervention.

Limite de Let's Encrypt

Let's Encrypt bloque temporairement un domaine après 5 validations échouées en une heure. Après 2 ou 3 échecs, arrête et cherche la cause avant de réessayer.

Changement de serveurs de noms pas encore propagé​

Après un changement de serveurs de noms chez WHC, il faut attendre :

  1. que le registre .ca enregistre le changement (en général quelques minutes) ;
  2. que Cloudflare passe le domaine en Active (souvent 1 à 2 heures, jusqu'à 24 h) ;
  3. que les caches des résolveurs DNS expirent (jusqu'à 24 h).

Pour vérifier :

  • Le registre : va sur lookup.icann.org et cherche formuleets.ca. La section Nameservers doit montrer les serveurs Cloudflare.

  • Les résolveurs publics :

    Resolve-DnsName formuleets.ca -Type NS -Server 1.1.1.1
astuce

Les commandes DNS directes vers les serveurs du registre (any.ca-servers.ca) échouent depuis le réseau de l'ÉTS. Utilise lookup.icann.org ou whatsmydns.net à la place.

Vérifier le DNSSEC​

Sous Windows, nslookup ne connaît pas le type DS. Utilise PowerShell :

Resolve-DnsName formuleets.ca -Type DS -Server 1.1.1.1

Si la réponse ne contient qu'un enregistrement SOA, le DNSSEC n'est pas actif. S'il était actif lors d'un changement de serveurs de noms, il faudrait le désactiver chez le registraire avant, sinon le domaine cesserait de résoudre.

Cloudflare refuse de créer un jeton d'API​

Message : « An unknown error occurred. Please verify your email. »

  1. Vérifie l'adresse courriel du compte Cloudflare (lien reçu par courriel, regarde aussi les indésirables).
  2. Déconnecte-toi de Cloudflare et reconnecte-toi : la page gardait l'ancien statut.
  3. Refais le jeton.

Ça marche sur PC, mais pas sur iPhone​

  1. Désactive le Relais privé iCloud (Réglages → ton nom → iCloud → Relais privé) et Limiter le suivi de l'adresse IP (Réglages → Wi‑Fi → (i) du réseau).
  2. Les applis mobiles (OpenProject, Bitwarden) exigent HTTPS avec un certificat valide. En HTTP, elles refusent de se connecter.