[Résolu] Erreur à l'activation du pare-feu

[ibanana]

Bonsoir à tous,

Premier message pour partager un souci que je rencontre. Je possède un DS1815+ sous DSM 6.2.4-25556.

Lorsque je souhaite activer le pare-feu (il s'est désactivé semble-t-il, mais quand? --> je l'ignore...), le Syno affiche le message : "Echec de l'application du profil du pare feu"

J'ai tenté de créer un autre profil (avant d'appuyer sur "appliquer" après avoir cocée "activer le pare-feu", idem, il me dit même que le profil existe déjà (alors que non) et refuse d'activer le pare-feu.

Parmis vous, quelqu'un saurait m'aiguiller?

 

D'avance merci 🙂

Modifié le 11 janvier 2022 par ibanana

[.Shad.]

Étrange comme problème, tu devrais ouvrir un ticket chez Synology en parallèle.

[ibanana]

Hello, merci pour ta réponse. La dernière intervention de leur SAV a été catastrophique, donc je demande d'abord aux passionnés 😉

[ibanana]

Hello, réponse de Synology : faut renvoyer avec perte de toutes les configurations + comme plus garanti, devis à prévoir.

Purée, je suis un peu sans solutions là.... d'autre ont une idée pour m'aider? 😌

Modifié le 11 juin 2021 par ibanana

[Torvic-Gall]

Le 11/06/2021 à 19:55, ibanana a dit :

Hello, réponse de Synology : faut renvoyer avec perte de toutes les configurations + comme plus garanti, devis à prévoir.

Purée, je suis un peu sans solutions là.... d'autre ont une idée pour m'aider? 😌

Salut

As-tu eu une réponse à ton problème ?  J'ai la même chose depuis aujourd’hui sur le mien, j'ai un DS218+.

[PiwiLAbruti]

Intéressant, il faudrait pouvoir supprimer les profils de pare-feu manuellement directement dans les fichiers de configuration de DSM.

J'y jetterai un œil si j'aime temps.

[Jeff777]

@PiwiLAbruti Comme j'ai (presque) tout mon temps, j'ai regardé pour faire progresser. En créant un nouveau profil les fichiers modifiés sont dans le répertoire (du moins sur DSM6 je n'ai pas regardé DSM7) :

usr/syno/etc/firwall.d/   qui contient les profils numérotés dans l'ordre de création 1.json, 2.json etc... et le paramétrage du profil firewall_settings.json (profil activé et son état).

Il y a également le fichier var/spool.webapi/*SYNO.Core.Security.firewall.json 

Je n'ai pas osé faire des tests 😆. Si quelqu'un a un nas de test pour faire une tentative de suppression de profil !

[PiwiLAbruti]

Supprimer, non. On peut remettre les fichiers de configuration par défaut.

Déjà, il faut voir l'état du parfe-feu en affichant le contenu de /usr/syno/etc/firewall.d/firewall_settings.json.

En suite il faut également afficher le contenu des profiles de pare-feu ({n}.json) pour voir les règles. S'il n'y a qu'un profil, seul un fichier 1.json est présent.

À parti de là on pourra éventuellement voir ce qui coince et restaurer la configuration par défaut.

[pluton212+]

il y a 51 minutes, Jeff777 a dit :

Je n'ai pas osé faire des tests 😆. Si quelqu'un a un nas de test pour faire une tentative de suppression de profil !

VirtualDSM ?

[Jeff777]

il y a 54 minutes, PiwiLAbruti a dit :

Déjà, il faut voir l'état du parfe-feu en affichant le contenu de /usr/syno/etc/firewall.d/firewall_settings.json.

Voilà ce que j'ai dans /usr/syno/etc/firewall.d/firewall_settings.json  avec un seul profil (fichier 1.json) :

 

Modifié le 29 novembre 2021 par Jeff777

[oracle7]

@Jeff777

Bonjour,

Chez moi j'avais conservé le profil originel "defaut" et avait créer un profil propre "monNas" que j'utilise par défaut (marqué "profile actif").

Je serais tenter de dire alors que pour le profil "monNas" qui apparaît dans le fichier " /usr/syno/etc/firewall.d/firewall_settings.json  ", qu'il suffit de passer "status" à false et le profil sera désactivé. Comme a priori le profil "defaut" existe toujours, on devrait basculer automatiquement sur lui. Je dis une c....ie ou pas ? Mais c'est peut-être une vision trop simple ...

Cordialement

oracle7😉

[Jeff777]

il y a 4 minutes, oracle7 a dit :

qu'il suffit de passer "status" à false et le profil sera désactivé

Sauf erreur, je crois que ce fichier ne contient que les info du profil actif. Il faut donc être prudent.

[Jeff777]

Pour être certain je viens de cloner mon profil par défaut, l'ai appelé Jeff777 et je l'ai activé. (curieusement son fichier n'est pas 2.json mais un nombre à dix chiffres !)

Dans le fichier de config j'ai maintenant:

{
   "profile" : "Jeff777",
   "status" : true
}
 

Si je le désactive j'ai :

{
   "profile" : "Jeff777",
   "status" : false
}

Donc oui le profil sera peut-être désactivé en mettant "false" mais je ne crois pas que le profil par défaut sera activé à sa place. On ne coupe pas à faire des tests sur un nas de test (ou VirtualDSM peut-être).

[PiwiLAbruti]

il y a 47 minutes, Jeff777 a dit :

Voilà ce que j'ai dans [...]

Ce qui m'intéresse est d'avoir le contenu des fichiers de configuration de quelqu'un qui a le problème comme @ibanana ou @Torvic-Gall.

S'il faut réinitialiser une configuration erronée, il faut que le fichier firewall_settings.json contienne,

{
   "profile" : "default",
   "status" : true
}

que le fichier 1.json contienne,

{
   "adapterPolicyMap" : {
      "global" : 2
   },
   "name" : "default",
   "rules" : null
}

Et que tout autre fichier {n}.json soit supprimé.

À partir de à il ne devrait plus y avoir de souci pour repartir sur une base propre.

[Torvic-Gall]

Il y a 20 heures, PiwiLAbruti a dit :

Ce qui m'intéresse est d'avoir le contenu des fichiers de configuration de quelqu'un qui a le problème comme @ibanana ou @Torvic-Gall.

S'il faut réinitialiser une configuration erronée, il faut que le fichier firewall_settings.json contienne,

{
   "profile" : "default",
   "status" : true
}

que le fichier 1.json contienne,

{
   "adapterPolicyMap" : {
      "global" : 2
   },
   "name" : "default",
   "rules" : null
}

Et que tout autre fichier {n}.json soit supprimé.

À partir de à il ne devrait plus y avoir de souci pour repartir sur une base propre.

Je ne suis pas chez moi pour l'instant (en vacance à la Réunion) et je ne suis pas certain d'avoir accès en SSH depuis ici (actuellement non activé mais peut-être indisponible en dehors de mon réseau local).
J'essaierai de l'activer et de faire un test avec PuTTY pour accéder aux dossiers et fichiers que vous mentionnez. 
Si j'ai la possibilité de "juste" modifier le .json pour le réactiver au lieu d'en faire un nouveau ça m'arrangerai, je ne sais plus tout ce qui est enregistré depuis bientôt 3 ans que je n'y ai pas touché.

Merci pour vos retour en tout cas

 

Je vous tiendrai au courant si j'ai le temps devant moi pour faire ça

NB : Après avoir contacté le SAV Synology, ils m'ont conseillé de faire l'étape 1 de RESET mais n'ayant pas d'accès physique je ne peux pas le faire non plus.

Modifié le 30 novembre 2021 par Torvic-Gall
Ajout complément information

[Torvic-Gall]

Salut @PiwiLAbruti

Alors j'ai réussi à accéder en ssh.  Dans le "firewall_setting.json" j'ai

Citation

{
   "profile" : "default",
   "status" : false
}

Dans le 1.json je n'ai pas
"rules" : null mais bien tout ce qui ressemble à ma configuration pare-feu.  Je ne vais peut-etre pas l'envoyer ici.

Par contre j'ai un 2.json qui lui est totalement vide.  Comme mentionné ci-dessus, je dois donc supprimer ce 2.json vide ?

Si je comprends donc bien, j'ai ma configuration pare-feu qui est bien là, dont le NAS n'arrive ni à charger le profil par défaut ni à activer le pare-feu en lui même.

J'ai également un troisième fichier qui se nomme meta.json et qui contient

Citation

{
   "custom" : {
      "fileName" : "2"
   },
   "default" : {
      "fileName" : "1"
   }
}

Le remplacement manuel de "false" par "True" peut-il permettre de forcer l'activation du pare-feu avec le 1.json ou ce n'est pas aussi simple ?

[PiwiLAbruti]

Supprime (ou déplace) les fichiers 2.json (qui est vide) et meta.json (qui ne devrait pas d'exister). Essaye ensuite d'activer le pare-feu dans DSM.

Si le problème persiste, il y a un souci dans le fichier 1.json. À toi de voir si tu trouves l'erreur dans ce fichier, sinon il faut le réinitialiser avec le contenu que j'ai posté plus haut.

 

[Torvic-Gall]

Il y a 2 heures, PiwiLAbruti a dit :

Supprime (ou déplace) les fichiers 2.json (qui est vide) et meta.json (qui ne devrait pas d'exister). Essaye ensuite d'activer le pare-feu dans DSM.

Si le problème persiste, il y a un souci dans le fichier 1.json. À toi de voir si tu trouves l'erreur dans ce fichier, sinon il faut le réinitialiser avec le contenu que j'ai posté plus haut.

 

C'est noté, je vais déplacer les deux puis d'activer le pare-feu dans DSM quand j'aurai un peu de temps devant moi.

Si ça ne fonctionne pas, je me pencherai sur le contenu du 1.json qui pourtant n'a pas été modifié depuis plus de deux ans.

Merci pour ta réponse.  Je reviendrai vous prévenir des résultats dans le cas ou quelqu'un d'autre ai le même problème

[ibanana]

Bonjour à tous,

Oulà!! Je n'avais pas vu toute cette activité. Merci pour votre aide, je vais regarder de près et vous fait un retour :)

Bon, j'ai tout relu, il va me falloir un peu d'aide, Tout se passe en SSH avec Putty si je comprend bien?

Quelqu'un peut-il m'éclairer sur les lignes de commandes à renseigner SVP? 🙂 Merci

[Jeff777]

il y a 20 minutes, ibanana a dit :

Oulà!! Je n'avais pas vu toute cette activité.

Bonjour,

Tout est relatif, ta dernière intervention date d'il y a plus de 6 mois 🤣

Par ailleurs tu pourrais en profiter pour faire ta présentation ici.

il y a 20 minutes, ibanana a dit :

Tout se passe en SSH avec Putty si je comprend bien?

Pour ce que tu as à faire, tu peux aussi utiliser Winscp c'est peut-être plus simple. En tout cas je trouve.

Mais attention aux fausses manips. Un tutoriel pour l'installer :

[ibanana]

Bonjour à tous,

Je suis finalement revenu vers le support et suis tombé sur une personne très compétente (Laurent W.) qui a su dépatouiller le bazard. Il s'agit bien d'une corruption de fichier telle que l'on écrit les personnes dans les messages ci dessus.

Merci à tous pour votre soutien!!! 🙂 

[Torvic-Gall]

Le 29/11/2021 à 14:40, PiwiLAbruti a dit :

Ce qui m'intéresse est d'avoir le contenu des fichiers de configuration de quelqu'un qui a le problème comme @ibanana ou @Torvic-Gall.

S'il faut réinitialiser une configuration erronée, il faut que le fichier firewall_settings.json contienne,

{
   "profile" : "default",
   "status" : true
}

que le fichier 1.json contienne,

{
   "adapterPolicyMap" : {
      "global" : 2
   },
   "name" : "default",
   "rules" : null
}

Et que tout autre fichier {n}.json soit supprimé.

À partir de à il ne devrait plus y avoir de souci pour repartir sur une base propre.

Alors comme promis, voici mon retour :

- Sous PuTTY : Suppression des deux fichiers inutiles à savoir 2.json et meta.json
- modification du firewall_settings.json => remplacement de "false" par "true" manuellement puis sauvegarde.

=> Pare-feu activé dans le syno (chose qui ne fonctionnait pas quand je voulais cocher la case depuis sécurité -> parefeu)

Passage à la deuxième étape les règles en elle-même :

-1ère tentative après activation du pare-feu : Echec avec le même message d'erreur "Echec de chargement des données du profil"
- J'ai donc déplacé le 1.json avec mes paramètres actuels (qui avaient + de 2 ans et dont je ne savais plus exactement ce qui était configurés) => Je n'avais donc que firewall_settings.json puis création d'un nouveau suivant les bases citée ci-dessus => Fonctionnel sous DSM je n'ai pas eu le fameux message d'erreur !
- Sous DSM donc, j'ai crée une nouvelle règle histoire de bien incrémenter ce 1.json pour commencer puis validation des changements.
- Sous PuTTY : Ouverture puis modification du 1.json en ajoutant 1 à 1 tous mes anciens paramètres en copier/coller depuis le 1.json déplacé ailleurs => La dernière règle était celle qui posait problème. Ne sachant pas précisément ce à quoi elle servait je ne l'ai donc pas rajouté. 
 

Tout re-fonctionne à nouveau comme avant !

Par sécurité, j'ai enregistré mes paramètres ailleurs dans un fichier txt histoire d'avoir simplement à copier/coller un fichier fonctionnel !

Merci à vous tous pour ces conseils et j'espère que mon retour permettra aux suivant sous DSM6 qui auront ce problème de pouvoir le résoudre.