Zedmos

8. Dépannage

Des symptômes, dans l'ordre où un ingénieur du support les prendrait. Le principe qui les sous-tend tous : trouvez le premier endroit où la vérité diffère de ce que vous attendiez, et arrêtez de deviner là.

La méthode

  1. Qu'est-ce qui a changé ? System → Configuration → History enregistre chaque changement et son auteur. La plupart des pannes ont vingt minutes.
  2. Le boîtier lui-même fonctionne-t-il ? Dashboard — services debout, passerelle active, disque pas plein.
  3. Où le trafic s'arrête-t-il ? Firewall → Log Files → Live View montre ce qui arrive et ce qu'on en fait. Si un paquet n'y est pas, il n'a jamais atteint le boîtier.
  4. Qu'a dit le service ? Chaque service a une page de journal, et la page d'état à côté répond en général à la question en une ligne.

Pas d'internet depuis le LAN

Le boîtier atteint l'internet ; les clients non.

  • Le client a-t-il une adresse ? Services → Kea DHCP → Leases DHCPv4. Pas de bail veut dire DHCP, pas routage : le serveur est-il actif sur cette interface, la plage est-elle dans le sous-réseau, y a-t-il un second serveur DHCP sur le segment ?
  • Sa passerelle est-elle le boîtier ? Vérifiez sur le client lui-même.
  • Sait-il résoudre les noms ? Si les noms échouent alors que les adresses marchent, c'est le DNS : regardez Services → Unbound DNS → General (le résolveur répond-il sur cette interface, et sa liste d'accès autorise-t-elle ce réseau ?).
  • Une règle le bloque-t-elle ? Firewall → Log Files → Live View, filtré sur l'adresse du client. Une interface neuve démarre sans rien d'autorisé — un VLAN tout frais sans règles se comporte exactement comme un réseau en panne.
  • Le trafic est-il traduit ? Firewall → NAT → Source NAT : un réseau que le boîtier ne traduit pas sort avec une adresse source privée et rien ne revient.

Une redirection de port ne marche pas

Travaillez du dedans vers le dehors, dans cet ordre :

  1. Firewall → Log Files → Live View — le paquet arrive-t-il sur le WAN ? Si non, le problème est en amont : votre opérateur, un modem en mode routeur, ou un autre pare-feu devant.
  2. Apparaît-il bloqué ? Alors la règle de pare-feu qui accompagne la redirection manque, est désactivée, ou se trouve sous une règle bloquante.
  3. Apparaît-il passé alors que le client n'obtient toujours rien ? Le serveur interne n'écoute pas, ou il a son propre pare-feu.
  4. Testez-vous depuis l'intérieur ? Un client du LAN qui atteint l'adresse WAN emprunte un autre chemin. Testez depuis l'extérieur.

Un VPN refuse de monter

WireGuardVPN → WireGuard → Status :

  • Pas de poignée de main : les deux bouts ne s'atteignent pas. Vérifiez la règle WAN pour le port d'écoute, et l'adresse d'extrémité du côté qui initie.
  • Poignée de main mais pas de trafic : routage ou règles. Les allowed IPs doivent couvrir les réseaux dans les deux sens, et l'interface du tunnel a besoin de règles.

IPsecVPN → IPsec → Log File, à lire par le bas. Le dernier message avant l'abandon nomme la discordance : les propositions (chiffrement et groupe DH) ou les sélecteurs de trafic, et les deux bouts doivent s'accorder exactement.

OpenVPNVPN → OpenVPN → Connection Status et son journal. Un client qui se connecte et est aussitôt éjecté a en général un problème de certificat — expiré, révoqué, ou émis par une autre autorité.

Enfermé dehors, hors du panneau

  • Mauvaise adresse ? System status sur la console imprime l'adresse du panneau.
  • Mauvais port ou mauvaise interface ? System → Settings → Administration peut déplacer le panneau ; la console montre où il a atterri.
  • Mot de passe refusé ? Menu de la console, Reset the root password — il règle ensemble le mot de passe de la console, de SSH et du web.
  • Une règle que vous venez d'écrire ? Le boîtier s'aperçoit qu'un changement a enfermé son administrateur dehors et annule ce changement de lui-même. S'il ne l'a pas fait, servez-vous de la console : Reload all services, ou System → Configuration → History pour reculer d'un pas une fois entré.
  • Rien ne marche et la machine est distante ? C'est à cela que servent le menu de la console et une sauvegarde de configuration. La remise en configuration d'usine est le dernier recours, et elle efface tout.

Un service refuse de démarrer

  1. System → Diagnostics → Services — est-il activé et dans quel état est-il ?
  2. Sa propre page Log File — la raison est presque toujours dans les dernières lignes.
  3. System → Log Files → Boot — s'il échoue au démarrage, voici le récit ordonné du pourquoi.

Deux causes récurrentes : un port déjà pris (deux services configurés pour répondre au DNS sur la même interface, par exemple), et un certificat manquant (un serveur VPN pointé sur un certificat qui a été supprimé).

Le boîtier est lent

  • System → Diagnostics → Activity — ce qui consomme le processeur.
  • Firewall → Diagnostics → Statistics — les états utilisés face à la limite. Approcher la limite explique des connexions qui échouent sous charge.
  • Dashboard → Resources — mémoire et disque. Un disque plein rend tout bizarre.
  • Avec le moteur de sécurité : l'inspection coûte du processeur. Security and Policy → Live Sessions montre ce qui est inspecté, et une exclusion pour le trafic de masse (sauvegardes, vidéo) récupère souvent plus que n'importe quel réglage fin.

L'heure est fausse

Services → Network Time → Status montre si un serveur est réellement retenu et quel est le décalage. Une horloge fausse casse la validation des certificats, la négociation VPN et chaque horodatage sur lequel vous compterez plus tard — corrigez-la avant d'enquêter sur quoi que ce soit qui en dépend.

Quoi envoyer au support

  • La version — System → Firmware → Status.
  • La liste des paquets — System → Firmware → Packages.
  • La page de journal pertinente, téléchargée en texte.
  • Ce que vous attendiez, ce qui s'est passé, et quand cela marchait pour la dernière fois.
  • Une sauvegarde de configuration seulement si on vous la demande, et par un canal auquel vous faites confiance : elle contient tous les secrets du boîtier.