darkneo

Je vais aller poser la question, mais j'ai la notification dans l'interface DSM, c'est ça qui me surprend aussi.... 🤔

Hello et merci pour le retour. Voilà le mail. Apparemment ça vient de surveillance station (certainement aussi pour ça que je le vois pas ban l'ip)

Bonjour à tous! Cela fait un moment que je n'étais pas passé; et je viens encore pour une "inquiétude". Cela fait 2j que je reçois un mail m'indiquant que mon compte admin est protégé... Alors que je l'ai désactivé dans DSM! Est ce que je dois m'inquiéter de ce genre de notification ou sont elles 'normales' et le compte est effectivement bien désactivé?

Suite au message de @Mic13710 sur un autre thread, j'ai finalement abandonné l'idée de remettre mon OpenVPN d'équerre avec mon certificat LE. J'ai donc : - Désactivé OpenVPN sur DSM - Généré un nouveau certificat autosigné avec Easy RSA - copié les fichier dans /volume1/... et modifié le .ovpn serveur pour lui indiquer les chemins des fichiers (je sais clairement pas si ca a servi a qqc) - Importé dans les certificat DSM (ca.crt, private key server et crt serveur) puis configurer VPN server pour utiliser ce nouveau certificat - Réactivé OpenVPN dans DSM Et hop, tout refonctionne (en ayant bien sur updaté la partie cliente pour utiliser les crt et key configuré pour le client). Je vous poste un lien qui m'a beaucoup orienté (car j'ai adapté quelques trucs mais les grandes lignes sont OK): https://tavenier.org/synology-nas-with-openvpn-with-client-certificate/

Je pense que c'est ce que je vais faire, car je trouve en plus pas mal de forum (en anglais) qui semblent dire que les certificats LE sont incompatibles avec certaines fonctionnalités d'OpenVPN (j'ai pas tout bien compris...). Concernant l'édit du fichier de conf, le "problème" c'est que je n'ai pas les fichiers CRT, PEM, et KEY... Donc il faudrait que je les génère... Donc autant tout refaire au propre avec un autosigné via easy RSA, ce qui me permettra en plus de pouvoir faire des clés pour chaque client que je veux utiliser! Merci pour l'info 👍

Hello à tous! Je viens poster ici car je pense qu'être passé sur la version Docker depuis l'ancien script basique a mis la pagaille dans ma config OpenVPN. J'ai posté un thread dédié ici: Pour faire court, j'ai l'impression qu'OpenVPN utilise encore l'ancienne version de mon certificat (qui a expiré) et j'aimerai m'assurer de pouvoir demander l'utilisation du nouveau certificat (mais du coup quels fichier utiliser?). Merci d'avance pour votre aide EDIT: A priori c'est confirmé, même en changeant le certificat dans l'interface Admin, le paquet VPN Server ne semble pas se mettre a jour correctement: https://serverfault.com/questions/1117955/how-to-use-public-certificates-with-openvpn-on-synology-dsm Du coup, obligé de passer par un easy RSA? ou de complètement désinstaller VPN Server pour le remettre?

Hello! Personne n'aurait une idée? Car je continue d'essayer de résoudre le problème et je tiens peut etre une piste... Ce soucis est apparu quand j'utilisais l'ancien script de renouvellement ACME (en local sur le syno). Suite aux différentes évolutions de Let's Encrypt, je suis passé sur la version docker d'Acme pour le renouvellement du certificat. Et je me dis que le soucis vient très certaintement de là! Dans la config serveur l'openvpn, il utilise les fihciers suivants: dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh3072.pem ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh3072.pem ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key Sauf que je pense que ces fichiers sont ceux de l'ancien script Acme. Avec la version docker, les fichiers se trouvent dans /volume1/docker/Acme/DOMAIN Je suis pas sur de mon coup, et je vois pas du tout comment avancer maintenant... Car dans ce dossier (/volume1/docker/Acme/DOMAIN), je n'ai ni fichier crt, ni fichier key, je n'ai que des csr: Une idée de commencer remplacer les certificat sur le serveur par ceux du docker Acme?

Hello à tous, Pour bien commencer l'année, je me prends la tête avec ma configuration VPN qui ne fonctionne plus... 😞 J'ai eu des soucis (voir sur un autre post) avec les certificats Let's Encrypt, donc j'ai tout refait, et tout reconfiguré (d'ailleurs pour info, ma demande de merge a été acceptée, donc le soucis LE pour le deploiement auto devrait être corrigé sous peu). Sauf que, depuis que j'ai mon nouveau certificat... Mon client VPN ne fonctionne plus 🤪 J'ai l'erreur suivante: Ce que j'ai tenté: - de base: export de la config VPN Server dans le zip, extraction, modification du fichier .ovpn pour y mettre mon DNS, même erreur - ajout des balises <cert> et <key> dans le fichier .ovpn, toujours la même erreur - comparaison du contenu de la balise <ca> avec mon chain.pem: il y a un bloc de plus dans le fichier .ovpn, mais si je le supprime, l'erreur change en me disant qu'il n'arrive pas à identifier le signataire du certificat Ce que j'ai vérifié: - le port est correctement ouvert dans le routeur. - J'ai vérifié le numéro de série du ca.cert, ce n'est pas le même que celui de l'erreur🤨 l'erreur me dit serial=1234567890 alors que dans le certificat j'ai un format hex (je pense, ca ressemble à un truc du genre 00912b09ef2394c) J'ai aussi essayé de récupérer directement les certificats depuis le dossier de mon docker via file station, même erreur... Autre point etrange: dans l'application VPN serveur, les connections sont bien affichées dans "Liste de connexion" avec mon ip, mais j'ai autant de session que mon paramètre max (5 en l'occurence) avec utilisateur à UNDEF Une idée de l'origine de ce blocage (je pense problème de certificat, mais pourquoi? et comment le changer?!) Merci d'avance pour votre aide! EDIT: J'ai oublié de préciser que les certificats téléchargés depuis l'app VPN server sont valides jusqu'en Sept 2025 (ca.crt et ca_bundle.crt) Par contre j'ai aussi l'impression que ce n'est pas le bon certificat qu'OpenVPN utilise, vu qu'il m'affiche ISRG Root X1 dans le certificat, alors que dans les logs il semble parler de DST Root CA X3.... c'est normal?

Pas tout à fait... Le Device ID (dans la version actuelle) est récupéré dans une réponse HTML (ligne 138 du code actuel) response=$(_get "$_base_url/webapi/$api_path?api=SYNO.API.Auth&version=$api_version&method=login&format=sid&account=$encoded_username&passwd=$encoded_password&otp_code=$otp_code&enable_syno_token=yes&enable_device_token=yes&device_name=$SYNO_Device_Name") Or, dans ma réponse, je n'ai pas de champ 'did' ou 'device_id', donc la variable reste systématiquement vide... (soit dit en passant, en plus, elle est totalement inutile car elle n'est pas nécessaire dans les HTML suivantes!) id_property='device_id' [ "${api_version}" -gt '6' ] || id_property='did' SYNO_Device_ID=$(echo "$response" | grep "$id_property" | sed -n 's/.*"'$id_property'" *: *"\([^"]*\).*/\1/p') _secure_debug2 SYNO_Device_ID "$SYNO_Device_ID"

Très certainement... Car en Septembre mon renew c'était fait sans soucis, et celui de Décembre était fail (et évidemment j'avais désactivé les notifications, donc je m'en suis aperçu car plus aucune service VPN, remote DSM etc ne fonctionnait). J'ai fait les propositions de modif dans le Github, on verra si elles sont acceptées, car pour le logout sur DSM 6, il faut utiliser auth.cgi (et non entry.cgi), et j'ai aussi rajouté le SID pour ne tuer que la connection initiée pour le renouvellement du certificat, ce qui me donne: [Fri Dec 22 13:57:37 UTC 2023] url='http://1.1.1.1:5000/webapi/auth.cgi?api=SYNO.API.Auth&version=6&method=logout&_sid=4oM5l6ohX206YB3J4N01003' [Fri Dec 22 13:57:37 UTC 2023] timeout= [Fri Dec 22 13:57:37 UTC 2023] curl exists=0 [Fri Dec 22 13:57:37 UTC 2023] mktemp exists=0 [Fri Dec 22 13:57:38 UTC 2023] wget exists=0 [Fri Dec 22 13:57:38 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L --trace-ascii /tmp/tmp.iuYADzae9v -g ' [Fri Dec 22 13:57:38 UTC 2023] ret='0' [Fri Dec 22 13:57:38 UTC 2023] response='{"success":true}' [Fri Dec 22 13:57:38 UTC 2023] Success En attendant, j'ai aussi passé l'autoupdate à 0 pour éviter toute prochaine déconvenue tant que la modification n'est pas acceptée/commitée. Et pour info, sans forcément passer par un SSH distant, depuis DSM, on peut aller dans l'interface du container pour lancer une commande custom, taper /bin/sh, ce qui ouvre un terminal directement dans le container (/bin/bash ne fonctionne pas car non installé dans le container).

Oui pas faux, mais entre mon NDD, les login/pwd et les ip parfois publiques... Bref.... Et non, je n'ai pas activé l'OTP sur mon NAS, mais a force de debug (et de recontruction d'URL), c'est la requpete qui est censée me retourner le Device ID qui ne le fait pas (dans la réponse, il n'y a pas le champ attendu). Certainement car je suis encore sur la version 6 de DSM (pour raison purement domotique, la version 7 et + ayant supprimer des drivers USB pour le RFXCom par exemple). EDIT: Je vais essayer de tester de plusieurs façon... Mais est ce que je peux techniquement changer un fichier dans un container sans passer par SSH... Car j'avoue ne jamais l'avoir fait (et je n'i qu'un accès remote à mon NAS, le remote SSH n'étant pas activé). EDIT2: Mon premier test a finalement été le bon.. Et le plus simple! J'ai rajouté un paramètre SAVED_SYNO_Device_ID dans le fichier de conf, et tout s'est déroulé... Presque sans encombre! A la fin, j'ai la fonction de logout qui ne fonctionne pas et me retourne un code 102... Je suppose que ce n'est pas aussi simple en DSM 6, il va falloir que je creuse

J'ai mis localhost pour obfusquer les logs (c'est vrai que j'aurai pu mettre autre chose...) mais en vrai j'ai bien la bonne ip... Pour preuve le SessionID et le Syno Token sont bien renseignés (avec localhost, ils auraient été vides 😉 ) J'ai report sur Github le soucis qui, je pense, est du à un mauvais if: if [ -z "$SYNO_DID" ] && [ -z "$SYNO_Device_ID" ] || [ -z "$sid" ] || [ -z "$token" ]; then Dans mon cas SYNO_DID et SYNO_Device_ID sont tous les 2 vides, vu que je n'utilise pas le 2 authentication factor, donc je rentre toujours dans cette loop.... car la requete ligne 138 ne me retourne jamais de Device ID.... 😞

Hello a tous, Ayant (encore) des problèmes avec mon renewal, j'ai décidé de franchir le pas de la version docker.. Mais je me retrouve avec exactement le même soucis: Impossible de se logguer pour enregistrer les certificats dans la dernière étape... Quand je lance la commande j'ai l'erreur: Le user n'a pas de Two factor authentication.... Et j'ai exactement la même erreur avec mon ancien script acme-renew.py.... Des hooks ont été changés pour le prendre que le two factor authent? Edit: En regardant un peu plus les logs... C'est étrange car il me trouve pourtant bien les sessionID & Compagnie, mais me dit qu'il n'arrive pas d'authentifier..... :0

Hello et merci pour le retour, Je viens de vérifier et cette option n'est pas activée... Donc ce n'est pas ça. malheureusement... Pour un peu plus de détail, dans la fenêtre du panneau de configuration, c'est les infos de mises à jour de DSM qui sont affichées (si jamais...)

Bonjour à tous, J'espère que vous allez tous bien depuis le temps? Une fois n'est pas coutume, je viens encore pour une question certainement très stupide: j'aimerai savoir comment désactiver l'ouverture de la fenêtre du panneau de configuration a chaque connexion? Car je me connecte souvent depuis des tablettes, etc et cette fenêtre, en plus de ne me servir a rien, n'est jamais correctement framé et ca me soule a chaque fois de devoir la fermer 😅 Merci d'avance pour votre aide!